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ABSTRACT 

This  thesis  analyzes  the  current  management  information  systems  in  place  at  Silas 
B.  Hays  Army  Community  Hospital  with  in  depth  research  into  the  hospital's  largest 
department,  the  Department  of  Family  Practice  and  Community  Medicine.  The  findings 
of  the  research  indicate  these  systems  are  not  meeting  the  needs  of  department 
managers  within  the  hospital.  This  thesis  contains  a  requirements  analysis  for  an 
improved  information  system  for  the  department.  The  process  of  identifying  the 
targeted  users,  selecting  the  appropriate  development  methodology,  and  identifying  the 
user's  information  requirements  is  discussed.  The  value  of  the  information  required  by 
the  department  manager,  both  in  content  and  format,  is  examined.  The  requirements 
analysis  is  based  on  a  combination  of  systems  development  life  cycle  and  prototyping 
methodologies  for  information  systems  development  and  can  be  used  to  design, 
construct,  and  implement  an  information  system  for  the  targeted  department.  The 
requirements  analysis  can  also  be  used  to  study  the  expandability  of  the  proposed 
information  system  to  departments  throughout  Silas  B.  Hays  Army  Community 
Hospital. 
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I.    INTRODUCTION 

A.      BACKGROUND 

Silas  B.  Hays  Army  Community  Hospital  (SBHACH)  is  a  large,  full  service 
medical  department  activity  (MEDDAC)  providing  health  care  to  active  duty,  retired, 
and  dependent  personnel  living  in  and  around  Fort  Ord.  The  MEDDAC  also  provides 
regional  medical  services  to  personnel  from  Hunter  Liggett  Military  Reservation, 
Presidio  of  Monterey,  Sacramento  Army  Depot,  United  States  Naval  Postgraduate 
School,  and  the  Sharpe  Army  Depot.  SBHACH's  annual  operating  budget  is  over  seven 
million  dollars  and  in  fiscal  year  1988,  over  460,000  patients  were  treated.  The 
hospital  consists  of  13  major  medical  departments  which  provide  inpatient  and 
outpatient  service,  major  surgical  services,  military  medical  support,  and  veterinary 
service.  In  addition,  SBHACH  is  a  teaching  hospital  for  Army  doctors  and  provides 
occupational  health  to  civilian  employees.  The  goal  of  SBHACH  is  to  provide  its 
patients  with  the  best  medical  care  possible. 

The  quality  of  the  medical  care  provided  depends  on  factors  such  as  the  quality 
of  the  hospital  personnel  and  the  effective  use  of  available  resources,  e.g.  personnel, 
money,  time,  and  medical  supplies.  Another  factor,  the  efficient  use  of  resources, 
indirectly  affects  the  quality  of  care  provided  because  this  factor  will  determine  the 
continued  availability  of  the  resources.  One  of  the  biggest  obstacles  SBHACH  faces 
in  trying  to  reach  its  goal  is  the  limited  resources  with  which  it  must  operate. 


SBHACH  doctors  and  administrators  must  constantly  deal  with  resource 
constraints.  They  are  continually  searching  for  more  efficient  and  effective  resource 
management  to  deal  with  these  constraints  while,  at  the  same  time,  improving  the 
quality  of  care  provided  to  the  patients.  In  searching  for  the  balance  between  cost 
efficiency  and  quality  of  care,  hospital  administrators  are  turning  to  information 
systems,  both  automated  and  manual,  in  the  belief  that  better  information  will  help 
them  operate  more  cost  effectively. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  study  the  current  management  information  systems 
in  place  at  Silas  B.  Hays  Army  Community  Hospital  and  determine  if  these  systems 
are  meeting  the  needs  of  department  managers  within  the  hospital.  In  identifying  the 
requirements  of  key  department  decision  makers,  we  will  propose  improvements  to  the 
information  system  where  the  current  system  fails  to  meet  the  department  manager's 
needs.  Ultimately,  the  thesis  will  provide  a  design  for  an  information  system  which  will 
meet  the  needs  of  department  decision  makers  more  effectively  and  efficiently  than 
current  systems. 

C.  SCOPE 

Due  to  time  limitations,  the  research  did  not  encompass  the  entire  hospital 
operation.  Therefore,  after  initial  interviews  and  some  detailed  study,  one  department 
was  selected  based  on  its  high  volume  and  overall  impact  on  the  hospital.  The 
department  chosen  for  the  research  was  the  Department  of  Family  Practice  and 
Community  Medicine  (DFPCM).  The  DFPCM  is  one  of  the  13  major  departments 


within  SBHACH  and  serves  nearly  53  percent  of  the  hospital's  patients.  An  additional 
motivation  for  limiting  the  scope  of  the  research  was  the  increased  depth  of  the 
analysis  and  design  of  an  information  system  that  would  otherwise  be  possible. 

In  addition  to  the  direct  study  of  the  DFPCM,  it  was  necessary  to  conduct 
research  in  the  many  supporting  units  which  influence  the  department's  overall  ability 
to  function.  The  following  support  divisions  were  contacted  during  the  course  of 
research: 

Resource  Management  Division 

Information  Management  Division 

Clinical  Support  Division 

Department  of  Nursing 

Logistics  Division 

Personnel  Division 

Patient  Administration  Division 

D.      METHODS  AND  ORGANIZATION 

The  thesis  research  followed  the  information  systems  development  life  cycle 
described  in  the  first  two  sections  of  Chapter  II.  Chapter  II  discusses  the  theory  of 
information  systems  and  the  analysis  and  design  of  such  systems.  The  last  section  of 
Chapter  II  introduces  the  application  of  information  systems  to  health  care.  Research 
was  conducted  to  discover  the  history,  current  status,  and  future  of  hospital  information 
systems  (HISs)  and  the  critical  nature  of  these  specialized  systems. 

The  DFPCM  organization  and  functions  are  described  in  detail  in  the  first  section 
of  Chapter  III.  Section  2  of  Chapter  III  discusses  the  results  of  the  current  systems 


analysis.  Data  Flow  Diagrams  (DFDs)  are  introduced  in  Chapter  HI.  DFDs 
diagrammatically  portray  the  current  information  systems  within  the  DFPCM. 

Chapter  IV  covers  the  requirements  for  improving  the  existing  information 
systems  within  the  DFPCM  and  how  these  improvements  can  be  accomplished  using 
an  automated  information  management  system.  The  findings  in  Chapter  IV  are  a  direct 
result  of  the  analysis  conducted  in  Chapter  in  and  described  what  is  necessary  for  the 
information  system  to  meet  the  needs  of  the  department  managers. 

The  detailed  systems  requirements  analysis  is  presented  in  Chapter  V, 
incorporating  the  functional  requirements  and  alternatives  selected  in  the  previous 
chapters.  User  Concept  Diagrams  (UCDs)  are  introduced  in  Chapter  V  to 
diagrammatically  portray  the  proposed  information  systems  for  the  DFPCM.  The 
requirements  analysis,  as  described  in  the  chapter,  is  for  the  DFPCM  alone.  This 
analysis  can  be  used  to  design  and  implement  a  management  information  system  for 
this  department,  or  with  additional  study,  may  be  expandable  to  other  clinics  within  the 
hospital. 

Conclusions  and  recommendations  resulting  from  this  thesis  are  given  in  Chapter 
VI.    Chapter  VI  also  suggests  directions  for  further  research  work. 


II.    INFORMATION  SYSTEMS 

A.  INTRODUCTION 

This  chapter  introduces  the  concepts  of  an  information  system  and  the  systems 
development  process  and  discusses  the  impact  of  information  systems  within  a  hospital 
environment. 

Section  B,  System  Design  Concepts,  describes  the  information  systems 
development  methodologies  used  in  the  thesis  to  design  the  information  system  for  the 
Department  of  Family  Practice  and  Community  Medicine.  The  process  of  selecting  the 
most  appropriate  system  development  methodology(ies)  is  also  examined. 

Section  C,  Hospital  Information  Systems  (HISs),  describes  the  critical  nature  of 
the  hospital  organization  and  it's  impact  on  the  role  of  information  systems  within  the 
hospital  environment,  both  historically  and  in  the  near  future.  Also  presented  in 
Section  C  is  a  description  of  the  information  systems  currently  used  at  SBHACH. 

B.  SYSTEMS  DESIGN  CONCEPTS 

An  information  system  has  been  described  as  a  collection  of  human, 
computerized,  and  mechanical  agents  that  work  together  to  acquire,  produce,  handle, 
store,  use,  and  disseminate  information  (Lockeman,  1986,  p.  617).  Information  systems 
are  meant  to  support  the  day  to  day  operations,  management,  and  decision  making 
needs  of  an  organization.  An  effective  information  system  does  not  necessarily  have 
to  be  automated.  Information  systems  exist,  with  or  without  automation,  because 
workers  within  the  organization  require  some  sort  of  a  system  to  collect,  process,  and 


exchange  the  information  they  need.  When  automation  is  deemed  necessary  and 
properly  designed,  it  can  provide  the  organization  with  an  increase  in  both  the 
efficiency  and  effectiveness  of  operations.  (Whitten,  Bently,  and  Ho,  1986,  p.  40) 

There  are  four  important  considerations  in  the  development  of  an  effective 
information  system.  First  and  foremost,  the  system  must  be  designed  to  serve  the 
needs  of  the  users.  The  analyst  has  a  responsibility  to  provide  the  user  with  a  product 
that  is  both  useful  and  correct.  Secondly,  the  analyst  should  understand  the 
organization's  mission  to  build  the  system  to  effectively  support  that  mission.  Thirdly, 
information  systems  provide  one  or  more  of  the  three  information  functions  depicted 
in  Table  I.  The  analyst  must  determine  which  of  these  functions  the  system  should 
support  and  how  the  information  system  will  fit  within  the  organization  to  fulfill  those 
functions.  Lastly,  the  system's  components,  as  depicted  in  Figure  1,  should  be 
designed  to  harmoniously  work  together  to  support  the  system's  intended  purpose 
within  the  organization.  (Whitten,  Bently,  and  Ho,  1986,  p.  692)  This  requires  the 
analyst  to  systematically  analyze  the  data  inputs,  data  flows,  processes,  and  information 
outputs.  (Kendall  and  Kendall,  1988,  p.  6) 
Table  I.  INFORMATION  FUNCTIONS 

Data  Processing  Systems 

Processes  large  amounts  of  data  for  routine  organization 

transactions. 

Management  Information  Systems 

Provides  periodic  reports  for  planning,  control  and  decision  making. 

Decision  Support  Systems 

Supports  decision  makers  by  providing  information  on  demand. 
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Computer  equipment  or  Hardware.  Information  systems  may  include  a  variety  of  hardware 
components,  including  copiers,  calculators,  and  computer  systems. 

Computer  Programs  or  Software.  A  system  is  a  mixture  of  programs  that  either  control  the 
computer  or  provide  applications  to  the  users. 

Users  (Knowledge  workers)  are  the  most  vita)  part  of  the  information  system's  components. 
They  are  the  central  theme  in  any  design  methodology. 

Methods  and   Procedures.  Methods  refer  to  how  the  system  works  whereas  procedures 
describe  how  to  perform  the  job  and  how  to  make  decisions. 

Data  Storage.  This  is  a  fundamental  component  of  the  system.  This  is  the  raw  data  that  must 
be  accessed  to  process  into  useful  information. 

Internal  Controls.  Feedback  and  control  are  system  concepts  that  must  be  added  to  any 
system  to  ensure  its  proper  operation. 


Figure  1.  Information  System  Components  (Whitten,  Bently,  and  Ho,  1986,  p.  692) 


Prior  to  attempting  the  design  of  an  information  system,  the  systems  analyst 
must  choose  a  design  methodology  which  will  best  meet  his  or  her  needs  and  the 
user's  needs.  This  selection  process  and  a  description  of  the  methodology  used  in  this 
thesis  is  described  in  the  following  sections. 

1.      Systems  Development  Life  Cycle  Methodology 

System  development  in  the  late  1960s1  was  often  behind  schedule,  over 
budget,  expensive,  and  poorly  suited  to  the  users'  requirements.  As  a  result,  the  early 
system  designers  developed  a  set  of  structured  methodologies  to  make  the  development 
process  more  orderly  and  manageable.  The  emergence  of  structured  methodologies 
provided  the  analyst  with  a  welcome  escape  from  the  haphazard  approaches  used  to 
develop  the  requirements,  specifications,  and  programs  used  in  the  early  design  models 
(Ceri,  1982,  p.  208). 

As  the  structured  approaches  became  accepted  as  a  viable  systems  design 
alternative,  more  analysts  began  to  perceive  that  the  structured  methodology  could  even 
be  further  improved  with  the  inclusion  of  a  life  cycle  within  the  model.  This  enhanced 
structured  approach,  dubbed  the  Systems  Development  Life  Cycle,  was  used  by  these 
analysts  to  bring  together  all  of  the  already  proven  systems  design  techniques  with  the 
successful  project  management  techniques.  This  system  development  life  cycle 
methodology  emerged  as  the  most  preferred  method  of  all  of  the  system  design 
methodologies.  (Wassermann,  1984,  p.  44) 


This  continues  to  be  the  case  in  the  eighties. 


Figure  2  portrays  the  Systems  Development  Life  Cycle  methodology.  This 
approach  provided  several  significant  advantages  over  the  non-structured  approaches  and 
the  early  forms  of  the  structured  methodologies.  This  design  approach  gave  the  systems 
analyst  a  better  understanding  of  the  user's  requirements  while  the  increasing  the  user's 
comprehension  and  participation  in  the  design  process.  (Willis,  Huston,  and  d'Ouville, 
1988,  p.  56)  Users  also  tended  to  be  a  lot  more  satisfied  with  the  final  outcome  of  a 
system  designed  using  this  methodology.  Information  systems  designed  using  this 
methodology  were  also  found  to  be  more  flexible  and  maintainable  then  the  early 
approaches.  (Sumner  and  Sitek,  1986,  p.  235) 

As  Figure  2  shows,  the  life  cycle  begins  with  a  project  development  request. 
Before  a  more  detailed  systems  study  is  started,  the  systems  analyst  surveys  the 
problem,  opportunity,  or  directive  that  initiated  the  request.  This  survey  is  used  to 
determine  whether  or  not  significant  resources  should  be  committed  to  the  project.  If 
the  system  development  is  approved,  the  development  enters  the  first  major  phase  of 
the  SDLC,  the  study  phase.  The  goal  of  the  study  phase  is  to  educate  the  analyst  about 
the  current  system,  thus  allowing  the  causes  and  effects  of  the  problems  to  be 
discovered.  This  type  of  analysis  is  presented  in  Chapter  IQ  of  this  thesis. 

The  next  phase,  the  requirements  phase,  is  the  most  critical  of  the  life  cycle 
phases  because  it  provides  the  foundation  for  all  subsequent  phases  (Willis,  Huston,  and 
d'Ouville,  1988,  p.  56).  This  phase  is  concerned  with  the  analyst  understanding  the 
problems  found  in  the  study  phase  and  describing  them  in  terms  of  the  activities,  data, 


information  flows,  relationships,  and  system  constraints  necessary  to  solve  the  problem 
(Ceri,  1982,  p.  205).  This  type  of  analysis  is  presented  in  Chapters  IV  and  V  of  this 
thesis. 


Start 


Knowledge 
Workers 


Finish 


Vendors 


Figure  2.  Systems  Development  Life  Cycle. 
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The  evaluation  phase  looks  at  how  the  new  system  should  be  developed.  The 
analyst  must  seek  out  all  possible  solutions  to  the  problem  and  generate  a  set  of 
alternative  proposals  to  solve  the  problem.  Each  alternative  is  then  evaluated  on 
technical,  operational,  and  economic  feasibility.  The  outcome  of  this  phase  should  be 
a  technically  feasible  solution.  (Whitten,  Bently,  and  Ho,  1986,  p.  149) 

If  this  solution  calls  for  new  hardware  or  software,  the  selection  phase 
becomes  necessary.  During  the  selection  phase,  the  analyst  determines  which  system 
specifications  are  important  for  the  equipment  or  software  required  for  the  new  system. 
Proposals  are  then  developed  and  sent  to  vendors.  Once  the  vendors'  proposals  are 
returned,  the  systems  analyst  selects  the  hardware  and  software  configurations  that  best 
meets  the  project's  needs  at  the  most  reasonable  cost.  (Whitten,  Bently,  and  Ho,  1986, 
p.  151) 

Given  the  user  requirements,  a  feasible  solution,  and  the  hardware  or 
software  configurations  from  the  selection  phase,  the  analyst  can  now  design  and 
construct  the  information  system.  Computer  outputs  are  normally  designed  first, 
followed  by  files/databases,  and  subsequently  the  user  inputs  and  terminal  dialogues. 
The  design  phase  is  where  system  controls,  as  implemented  in  methods  and  procedures, 
first  enter  the  developmental  life  cycle.  The  deliverable  of  this  phase  is  the  completed 
design  specification  and  the  preliminary  procedures  necessary  for  the  construction  of 
the  new  system.  The  construction  and  design  phases  are  frequently  the  most  time 
consuming  and  tedious  phases,  particularly  if  the  requirements  are  incomplete  or  do  not 
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reflect  the  actual  user's  requirements.  Finally  the  system  is  delivered,  the  users  are 
trained,  and  the  system  enters  the  maintenance  phase.  (Whitten,  Bently,  and  Ho,  1986, 
pp.  151-155) 

Throughout  the  various  phases,  the  analyst  is  collecting  facts,  documenting 
the  system,  presenting  ideas,  and  reevaluating  the  feasibility  of  the  system.  All  of  the 
phases  of  the  system  development  life  cycle  are  not  discreet  and  distinct  phases.  Figure 
3  illustrates  how  each  phase  can  overlap  within  the  life  cycle.  (Whitten,  Bently,  and 
Ho,  1986,  p.  157)  As  a  life  cycle  model  should  indicate,  the  process  will  begin  again 
as  new  project  requests  are  generated,  the  organization  evolves,  or  the  system  once 
again  fails  to  meet  the  user's  requirements. 


Activity 
Survey  the  Situation 

Study  the  Current  System 

Define  User  Requirements 

Evaluate  Alternative  Solutions 
Select  New  Computer 
Equipment  and  Software 

Design  the  New  System 

Construct  the  New  System 

Deliver  the  New  System 
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Figure  3.  Overlap  Opportunities  within  the  Systems  Development  Life  Cycle.  (Whitten, 
Bently,  and  Ho,  1986,  p.  157) 

In  spite  of  the  large  number  of  structured  methodologies  available,  this  type 

of  systems  analysis  is  not  widely  used  (Sumner  and  Sitek,  1986,  p.  235).    Today,  only 

about  ten  percent  of  the  data  processing  organizations  in  North  America  practice 
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structured  techniques  in  a  disciplined  fashion  even  though  90%  of  the  community  is 
at  least  superficially  familiar  with  the  basic  concepts  (Yourdon,  1986,  p.  133). 

Prior  to  selecting  the  use  of  one  of  these  methodologies  in  our  thesis,  a 
closer  look  was  taken  to  determine  why  these  methodologies,  so  often  taught  at 
universities,  were  not  being  used.  Yourdon  explains  that  there  are  many  reasons  for  this 
reversal  in  the  attitudes  toward  structured  analysis.  He  felt  that  the  primary  reason  for 
this  reversal  was  the  frustration  of  analysts  over  the  amount  of  manual  labor  required 
to  develop  systems  using  the  structured  methodologies.  Analysts  in  a  real  business 
environment  did  not  have  the  time  to  do  the  time  consuming  requirements 
documentation  necessary  for  the  requirements  analysis  when  there  was  a  large  backlog 
of  projects  awaiting  development.  The  analysts  also  became  increasingly  frustrated 
with  the  inability  to  apply  these  methodologies  to  complex,  real-time  systems. 
(Yourdon,  1986,  p.  133)  Additionally,  many  systems  analysts  were  not  trained  in  the 
use  of  the  methodologies  and  tools  and  were  unsure  as  to  which  tools  could  be 
effectively  used  within  the  phases  of  the  life  cycle  (Ceri,  1982,  p.  208).  One  of  the 
major  reasons  for  this  reversal  of  attitudes  was  the  development  of  the  prototyping 
methodologies  discussed  in  the  following  section.  Many  analysts  were  lured  away 
from  the  structured  approaches  to  systems  development  by  the  promise  that  prototyping 
could  be  used  to  interactively  design  and  progressively  tune  the  systems  design  without 
the  rigorous  requirements  of  the  structured  approaches  (Ceri,  1982,  p.  208). 

Too  often,  even  though  the  structured  techniques  were  used,  the  end  result 
was  a  better  design  that  still  did  not  meet  the  users'  needs.  Because  of  the  time  lag 
between  the  analysis  and  implementation  phases  in  the  structured  methodology,  the 
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users'  environment  changed  even  after  the  system's  requirements  were  set  in  the 
requirements  and  design  phases.  The  users  also  had  difficulty  communicating  their 
requirements  to  the  analyst.  Senn  points  out  "users  can  point  to  features  they  like  or 
dislike  in  an  existing  system  more  easily  than  they  can  describe  them  in  an  imaginary 
or  proposed  system."  (Senn,  1987,  p.  611)  These  observations  led  to  the  conclusion 
that  a  better  design  methodology  was  needed  to  meet  system  development  requirements. 
2.      Prototyping  Methodologies 

Information  systems  analysts  saw  the  need  for  an  improved  design  method. 
They  felt  that  any  systems  development  approach  required  the  concurrent  learning  of 
both  the  analyst  and  the  users.  During  the  requirements  phase,  the  major  functions  of 
the  analyst  are  to  help  users  formalize  their  tasks  and  decision  processes,  ensure  that 
the  users  learn  the  analyst's  modeling  techniques,  and  help  the  users  understand  the 
scope  of  the  project  (Cerveny,  1987,  p.98).  The  structured  methodologies  simply  did 
not  fulfill  this  requirement.  Recent  developments  in  computer  technology,  primarily  the 
introduction  of  user  friendly  code  generators,  allowed  the  systems  analysts  to  develop 
a  better  approach  to  the  systems  development  process.  This  new  approach,  prototyping, 
was  designed  to  alleviate  some  of  the  problems  that  concerned  the  systems  analysts 
about  the  traditional  approaches.  (Willis,  Huston,  and  d'Ouville,  1988,  p.  57) 

The  concept  of  prototyping  is  not  new.  In  engineering,  prototyping  has  long 
been  a  standard  for  developing  and  testing  new  products  and  systems  (Scharer,  1983, 
p.  60).  Prototyping  was  not  designed  to  replace  the  systems  development  life  cycle. 
Instead,  prototyping  enhances  the  life  cycle  by  promoting  the  mutual  learning  processes 
between  the  analyst  and  user  (Cerveny,  1987,  p.  98,  103).    Prototyping  uses  the  power 
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of  demonstration  to  enable  the  user  and  the  analyst  to  literally  see  their  specification 

in  action  (Scharer,  1983,  p.  60).    Prototyping  has  the  following  significant  advantages 

over  the  traditional  structured  methodologies: 

Gets  the  user  more  actively  involved  in  design  and  development. 

Provides  the  user  with  a  tangible  means  of  comprehending  and  evaluating  the 
proposed  system. 

Achieves  more  meaningful  user  feedback  in  terms  of  their  needs  and 
requirements. 

Develops  better  relationships  between  systems  analysts  and  user  groups. 

Results  in  fewer  post  implementation  changes,  resulting  in  lower  maintenance 
costs.  (Kroenke,  1987,  p.  157) 

The  system  that  had  been  prototyped  could  be  developed  in  one  quarter  of  the 
time  required  of  the  structured  methodologies.  (Willis,  Huston,  and  d'Ouville, 
1988,  p.  58)  (Harrison,  1985) 

The  main  benefit  of  using  a  prototype  methodology  is  the  development  of 
an  information  system  that  more  closely  fits  the  needs  of  the  organization.  Prototyping 
also  reduces  the  risks  involved  with  the  development  cycle  by  getting  the  system  into 
operation  quickly  and  keeping  the  system  simple.  (Cerveny,  1987,  p. 57)  Prototyping 
is  not  superior  to  the  traditional  methods  in  all  cases.  Table  II  depicts  the  factors  that 
favor  either  the  traditional  or  prototype  methodologies. 

Figure  4  depicts  the  modified  systems  development  life  cycle  where 
prototyping  techniques  have  been  integrated  into  the  life  cycle.  After  the  users  have 
specified  their  needs,  the  analyst  can  then  demonstrate  how  the  proposed  system  can 
meet  those  needs.  Design  by  prototyping  consolidates  the  requirements  definition, 
design,  and  construction  stages  of  the  typical  system  development  life  cycle  discussed 
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earlier.  These  three  activities  take  up  approximately  60  percent  of  the  manhours 

required  for  a  system  study.  Consequently,  prototyping  yields  a  net  saving  in  effort 

when  it  is  utilized  in  the  design  of  information  systems.  (Willis,  Huston,  and  d'Ouville, 

1988,  p.  58) 

Table  II.  FACTORS   FAVORING   ALTERNATIVE  DEVELOPMENT  METHODS 
(Willis,  Huston,  and  d'Ouville,  1988,  p.  58) 

Project  Characteristics  of  Alternative  Development  Methods 

Factors  Favoring  Traditional  Systems  Development 

•  Data  needs  are  clearly  defined. 

•  Systems  have  long  life  expectancy. 

•  Tight  controls  are  required. 

•  Development  risks  are  clearly  defined. 

•  Essential  system  features  are  known  in  advance. 

•  Operational  characteristics  are  well  understood. 

Factors  Favoring  Prototyping 

•  User  requirements  are  uncertain. 

•  Procedure  changes  are  extensive. 

•  User  environment  is  volatile. 

•  System  has  relatively  short  life  expectancy. 

•  System  needs  to  be  operational  in  short  period  of  time. 

•  Changes  in  specifications  are  anticipated. 

The  construction  of  a  prototype  model  requires  that  the  systems  analyst 

follow  the  six  basic  steps  listed  in  Table  HI  and  described  below. 

Table  III.   STEPS  IN  PROTOTYPE  DEVELOPMENT  (Willis,  Huston,  and  d'Ouville, 
1988,  p.  57) 

Prototyping  Design  Steps 

1.  Select  an  appropriate  application. 

2.  Identify  basic  needs. 

3.  Develop  the  working  model. 

4.  Refine  the  model  and  system  interface  characteristics. 

5.  Implement  revisions  and  enhancements. 

6.  Prepare  prototype  documentation  and  plan  for  development. 
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Figure  4.    Prototyping  Systems  Development  Life  Cycle 
a.      Step  One:  Select  Appropriate  Application 

The  first  consideration  for  the  systems  analyst  is  to  determine  if  the 
system  under  development  favors  the  prototyping  design  methodology.  This 
methodology  is  not  superior  to  the  structured  approaches  in  all  cases.  The  analyst  takes 
into  consideration  all  the  factors  listed  in  Table  II,  Factors  Favoring  Alternative 
Development  Methods,  the  user's  environment,  and  the  availability  of  prototyping  tools 
to  determine  if  the  system  can  best  be  developed  with  the  prototyping  approach. 
(Willis,  Huston,  and  d'Ouville,  1988,  p.  58) 
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The  environment  within  the  DFPCM  favored  the  use  of  prototyping  for 
the  following  reasons: 

•  Uncertain  user  requirements. 

•  The  environment  was  particularly  unstable,  subject  to  wide  swings  of  personnel 
availability  and  work  procedures. 

•  The  new  system  is  needed  immediately  to  meet  the  department's  expanding 
role  within  the  hospital. 

•  The  system  was  expected  to  have  a  relatively  short  life  cycle. 

•  Numerous  changes  were  expected  in  the  specifications,  as  reports,  procedures, 
and  requirements  for  information  appeared  to  be  changing  daily. 

b.  Step  Two:  Identify  Basic  Needs 

The  second  step  in  prototyping  involves  getting  a  better  understanding 
of  the  problem  or  opportunity  that  was  developed  in  the  study  phase.  (Willis,  Huston, 
and  d'Ouville,  1988,  p.  59)  The  goal  of  this  step  is  to  develop  enough  of  an 
understanding  of  the  problem  to  enable  the  design  and  construction  of  the  initial 
prototype  model  (Boar,  1984,  p.  67). 

c.  Step  Three:  Develop  Working  Model 

The  purpose  of  this  step  is  to  build  the  initial  version  of  the  prototype. 
Screens  and  documents  layout  are  defined,  data  records  are  specified,  and  other  model 
characteristics  are  established  (Willis,  Huston,  and  d'Ouville,  1988,  p.  59).  Content, 
not  presentation,  should  be  the  primary  goal  of  this  initial  model  (Boar,  1984,  p.  69) 
The  analyst's  intent,  in  this  stage,  is  not  to  come  up  with  the  perfect  model  but  to 
develop  a  model  that  best  matches  the  user's  view  of  the  problem.  Quality  is  critical. 
If  the   model   is   incomplete,   it   results   in   a  poor   foundation   for  the   rest   of  the 
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development  cycle.  The  target  time  for  delivery  of  the  initial  model,  depending  on  the 
prototype  environment,  should  be  three  to  six  weeks.  (Boar,  1984,  p.  69) 

d.  Step  Four:  Refine  Model  and  System  Interface  Characteristics 

In  this  step,  the  system  is  refined  so  that  each  of  the  initial  prototypes 
tested  earlier  are  now  required  to  work  together.  The  analyst's  goal  in  this  step  is  to 
immediately  test  new  ideas  to  see  what  refinements  will  satisfy  the  majority  of  the 
users.  As  users  review  this  refined  prototype  and  changes  are  made,  the  important 
changes  are  documented  for  later  reference.  (Willis,  Huston,  and  d'Ouville,  1988,  p.  59) 

e.  Step  Five:  Implement  Revisions  and  Enhancements 

The    objective    of  this    step   is   to    allow   the   users   to   review    the 

information  system  in  as  complete  a  context  as  possible.  This  review  occurs  after  all 

the   changes   and   enhancements   have   been   implemented   and   serves   as   the   final 

evaluation  of  the  information  system  in  the  eyes  of  the  user.  (Willis,  Huston,  and 

d'Ouville,   1988,  p.   59)      Except  for  minor  problems,  the  prototype  is  essentially 

complete. 

/.       Step     Six:     Prepare     Prototype     Documentation     and    Plan    for 
Development 

This   stage   of  the  prototype  cycle   involves  the  completion  of  the 

documentation  for  the  system  and  the  determination  of  the  fate  of  the  prototype.  The 

format  and  the  extent  of  the  documentation  rests  largely  with  the  project  manager.  The 

final  decision  is  made  concerning  how  the  prototype  should  be  used  in  the  new  system. 

At  this  stage  the  analyst  can  go  in  three  directions  with  the  prototype. 
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•  If  the  implementation  of  this  prototype  is  too  expensive  or  infeasible,  the 
system  can  be  abandoned. 

•  Depending  on  the  analyst's  prototyping  development  tools,  the  prototype  could 
actually  be  implemented  directly. 

•  As  is  the  case  with  this  thesis,  the  prototype  could  be  used  simply  as  a  step 
to  another  stage  of  the  development  process.  The  prototype  provides  the 
analyst  with  a  knowledge  base  for  the  design  of  the  new  system.  (Willis, 
Huston,  and  d'Ouville,  1988,  p.  59) 

The  successful  prototype  clearly  enhances  the  traditional  approaches.  It 

is  usually  considerably  cheaper,  less  risky,  and  conveniently  keeps  the  system  simple 

from  the  user's  perspective.  It's  primary  advantage  is  that  it  allows  the  user  to  see  the 

application  in  its  operational  context  and  determine  if  the  current  design  fits  his  or  her 

needs.  (Willis,  Huston,  and  d'Ouville,  1988,  p.60) 

C.      HOSPITAL  INFORMATION  SYSTEMS  (HIS) 

1.      The  Critical  Nature  of  Hospital  Information  Systems 

The  health  care  delivery  system  in  a  hospital  environment  is  generally 
viewed  as  an  industry.  This  industry  has  seen  major  changes  in  recent  decades  due  to 
breakthroughs  in  medicine  and  technology.  The  cost  of  health  care  nationwide  has 
increased  more  than  tenfold  since  1950  to  over  $120  billion  making  health  care  one 
of  this  nation's  largest  industries  (Rakich  and  Darr,  1978,  p.  1).  In  addition  to  the 
major  changes  taking  place  in  the  health  care  industry,  the  very  nature  of  health  care 
delivery  creates  a  complex  organization  for  the  hospital  administrator.  Rakich  and  Darr 
suggest  the  hospital  is  one  of  the  most  complex  organizations  in  existence  based  on  the 
characteristics  discussed  below. 
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•  There  is  a  wide  diversity  of  objectives  and  goals  for  different  personnel  and 
subsystems  (e.g.,  patient  care,  education,  research,  accommodations, 
administration). 

•  The  diversity  of  personnel  ranges  from  highly  skilled  physicians  and 
administrators  to  unskilled  laborers. 

•  The  hospital  is  in  continual  operation. 

•  Hospitals  deal  with  life  and  death  decisions. 

•  Measuring  the  major  product  (patient  care)  is  difficult.  (Rakich  and  Darr,  1978, 
p.  1) 

These  often  conflicting  attributes  can  cause  problems  for  hospital  decision 
makers.  A  dichotomy  is  created  by  the  conflicting  goals  of  the  hospital's  two 
components,  management  and  operations,  and  becomes  most  evident  and  important  in 
an  environment  where  societal  pressures  and  legal  implications  concerning  ethical 
behavior  are  greatest.  The  non-medical  management  component  (sometimes  referred  to 
as  "bean  counters")  measures  efficiency,  i.e.,  the  maximum  amount  of  output  (hospital 
services)  for  a  given  input  (cost).  The  medical  component  (health  care  providers) 
measures  performance  by  the  quality  of  care  provided  to  the  patient  (Longest,  1978, 
p.  125).  This  difference  of  purpose  and  objective  will  impact  the  manner  in  which 
information  is  managed  and  used  in  the  hospital  environment.  Figure  5  is  a  humorous 
portrayal  of  the  conflicts  which  exist  between  doctors  and  administrators  when 
considering  the  use  of  computer  resources  (Cowey  and  McAlister,  1980,  p.  141). 
However,  the  consequences  of  such  conflicts  are  quite  serious  and  play  an  important 
role  in  the  potential  effectiveness  of  a  hospital  information  system  (HIS). 

Another  factor  influencing  the  HIS  is  the  complexity  of  the  relationship 
between  the  doctor  and  the  patient.     The  ethics  and  responsibilities  involved  make 
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doctors  wary  of  new  technologies  and  methods  unless  the  benefits  to  the  patients  can 
be  proven.  (Safir,  1978,  p.  98) 
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Figure  5.    Conflicts 

The  complexity  and  significance  of  health  care  organizations  described  in  the 
preceding  paragraphs  creates  a  critical  environment  for  a  HIS.  The  conflicts  which  exist 
have  affected  the  use  and  advancement  of  HISs  throughout  their  life  span  and  continue 
to  influence  the  way  in  which  hospital  personnel  view  the  quality  and  effectiveness  of 
the  HIS.  (Safir,  1978,  p.  98) 

2.      HIS  Environmental  Overview 

Early  hospital  information  systems  were  developed  primarily  to  support 
hospital  administration.  Hospitals  applied  computer  resources  in  conventional  ways  for 
accounting  and  other  business  related  administration.  Computers  were  also  used  in 
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medical  research  but  were  not  generally  considered  suitable  for  directly  supporting  the 
medical  care  given  to  patients. 

Figure  6  (Cowey  and  McAlister,  1980,  p.  137)  shows  three  main  areas 
where  medical  computing  can  be  applied  in  a  hospital  environment.  The  two  large 
circles  represent  the  more  traditional  applications  of  computers  in  health  care, 
administration  and  research.  The  intersection  of  these  circles  represents  the  area  of 
medical  computing  related  to  the  care  provided  to  patients.  This  area  overlaps  both 
medical  research  computing  and  administrative  computing  and  is  affected  by  the 
conflicting  objectives  of  doctors  and  managers  discussed  earlier.  We  targeted  this  area 
of  medical  computing  in  our  research  and  found  a  tremendous  lag  in  the  computer 
technology  applied  to  medical  care  delivery. 


Figure  6.  Three  Areas  of  Medical  Computing 
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Experts  in  both  the  medical  and  computer  fields  began  to  recognize  the 

medical  computing  lag  in  the  mid-1970s  and  have  made  concerted  efforts  to  catch  up. 

A  Symposium  on  Computer  Applications  in  Medical  Care  (SCAMC)  has  met  annually 

since  1976.  In  1978,  hearings  were  held  before  the  Subcommittee  on  Domestic  and 

International  Scientific  Planning,  Analysis  and  Cooperation  to  discuss  the  topic  of 

computers  in  health  care.    The  reasons  for  the  medical  computing  lag  can  be  traced 

back  to  the  critical  nature  of  the  HIS  introduced  in  the  previous  section.    In  1978, 

Aran  Safir  M.D.  wrote: 

...the  complexity  that  characterizes  human  interactions  is  perhaps  nowhere  better 
demonstrated  than  in  the  relationship  of  doctor  and  patient.  Representing  such 
complex  human  interactions  effectively  within  the  computer  is  exceedingly 
difficult.  (Safir,  1978,  p.  98). 

In  1980,  Cowey  and  McAlister  found  it  was  rare  for  hospitals  to  devote  a 
portion  of  its  budget  to  data  processing  equivalent  to  that  spent  by  most  other 
industries  of  comparable  size  (Cowey  and  McAlister,  1980,  p.  vi).  The  following 
barriers  to  medical  computing  were  suggested  in  1985  by  Bonnie  Kaplan,  Ph.D.  at  the 
annual  SCAMC  symposium  (Kaplan,  1985,  p.  400): 

•  Lack  of  funding,  technology,  staffing,  training,  and  effort. 

•  Poor  management  including  difficulties  of  interdisciplinary  teams,  planning  and 
approach,  and  lack  of  attention  to  human  factors  and  methodologies. 

•  Difficulty  of  translating  medical  knowledge  into  a  form  suitable  for  computing. 

•  Institutional  constraints  and  physician  resistance. 

These  barriers  will  exist  to  some  degree  in  every  organization.  Many 
hospitals  are  attempting  to  hurdle  the  barriers  through  improved  communication  and 
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cooperation  between  doctors  and  administrators.  Large  hospitals  are  moving  toward  a 
HIS  which  integrates  administrative,  research,  and  medical  service  computing  into  one 
complete  system.  An  example  of  an  integrated  HIS  is  the  University  Hospital 
Information  System  (UHIS),  introduced  in  1980  when  the  University  Hospital  at  State 
University  of  New  York  first  opened  its  doors.  UHIS  offered  a  wide  range  of  patient 
care  services  including  registration,  medical  records,  automated  lab  data,  quality  control, 
pharmacy,  radiology  and  nursing  (Vegoda  and  Dyro,  1986,  p.  261). 

The  medical  computing  future  shows  a  trend  toward  increased  integration  of 
hospital  information  system  functions  like  that  described  in  the  UHIS.  The  Yale-New 
Haven  Hospital  began  implementing  the  Patient  Care  Support  System  (PCSS)  in  1986. 
PCSS  is  expected  to  take  several  years  to  implement.  When  complete,  PCSS  is 
expected  to  improve  the  quality  of  care  rendered  to  patients  by  allowing  physicians  to 
more  efficiently  and  accurately  order  tests,  lab  work,  and  prescriptions.  Medical  record 
tracking  and  results  reporting  is  also  expected  to  improve  (Sadock,  1986,  p.  114). 

The  Department  of  Defense's  answer  to  an  integrated  HIS  is  the  Composite 
Health  Care  System  (CHCS)  scheduled  for  completion  in  1991.  The  objectives  for 
CHCS  include:  "improving  the  quality  of  patient  care,  increasing  the  efficiency  of 
operations,  increasing  the  accuracy  and  availability  of  information,  and  providing 
standardized,  but  flexible  support."  (Regional  Training  Conference  Manual,  1988,  p. 
135).  In  1988,  a  Regional  Training  Conference  was  held  in  Monterey,  CA  to  update 
attending  medical  professionals  on  military  and  other  government  medical  information 
system  initiatives  (Regional  Training  Conference  Manual,  1988).  One  of  the  topics 
covered  at  the  conference  was  the  planned  implementation  of  CHCS.    The  following 
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patient  care  benefits  of  the  CHCS  were  cited  (Regional  Training  Conference  Manual, 
1988,  p.  140): 

•  Improved  quality  of  care. 

•  Reduced  time  spent  handling  information. 

•  Improved  management  control  of  operations. 

•  Increased  patient  satisfaction. 

•  Increased  compliance  with  standards  and  regulations. 

•  Increased  service  capacity  with  same  staff  levels. 

•  Improved  personnel  morale  and  job  satisfaction. 

Doctors  and  hospital  administrators  are  trying  to  recover  from  the  medical 
computing  lag  which  has  continually  plagued  the  industry.  They  are  beginning  to 
realize  the  importance  of  quality  information  for  providing  high  quality  patient  care. 
Integrated  HISs  are  the  future  for  medical  computing  and,  if  properly  used,  will  enable 
the  health  care  industry  to  provide  better  quality  medical  care. 

3.  Information  Technology  at  Silas  B.  Hays  Army  Community  Hospital 
The  current  information  technology  at  Silas  B.  Hays  Hospital  consists  of 
three  major  systems,  the  Medical  Expense  and  Performance  Reporting  System 
(MEPRS),  the  Automated  Quality  of  Care  Evaluation  Support  System  (AQCESS),  and 
the  Computer  Stored  Ambulatory  Record  System  (COSTARS).  These  three  systems  are 
completely  independent  and  are  maintained  through  separate  government  contracts.  No 
attempt  has  been  made  to  link  these  information  systems  into  one  large  database. 
Because  of  the  inherent  incompatibility  of  the  systems  and  the  eminent  arrival  of  the 
Composite  Health  Care  System,  SBHACH  administrators  believe  it  would  be  cost 
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prohibitive  to  attempt  systems  integration  at  this  time.  The  next  three  sections  describe 
the  basic  function  of  each  of  these  systems. 
a.      MEPRS 

The  purpose  of  MEPRS  is  to  collect,  process,  and  report  to  the  Health 
Services  Command  (HSC)  all  data  on  the  medical  workload,  staffing,  and  expenses 
incurred  by  each  workcenter  within  the  hospital  (Regional  Training  Conference,  1988, 
p.  47).  Each  hospital  department  maintains  various  worksheets  to  record  manpower 
utilization  and  workcenter  expenses.  Each  department  reports  the  hours  for  clinicians 
(doctors)  and  non-clinicians  (all  others)  to  the  MEPRS  section,  a  subdivision  of  the 
Resource  Management  Division  (RMD).  Also  recorded  are  the  inpatient  bed  days  and 
the  number  of  outpatient  visits  for  each  of  the  workcenters.  This  workload  information 
is  maintained  in  both  the  AQCESS  and  COSTARS  systems  but  because  the  systems 
are  incompatible,  the  data  must  be  manually  extracted  from  each  of  the  systems  for 
entry  into  the  MEPRS  system.  Direct  expense  data  on  such  items  as  electricity  and 
water  is  received  from  the  Fort  Ord  Finance  and  Accounting  Office  and  manually 
extracted  by  the  MEPRS  personnel  and  recalculated  based  on  the  square  footage  of 
each  departments'  assigned  space.  This  expense  information  is  then  manually  entered 
into  the  MEPRS  computer.  Each  month  all  hospital  data  is  loaded  onto  a  magnetic 
tape  and  sent  to  the  Health  Services  Command  (HSC)  at  Fort  Sam  Houston,  Texas. 
The  data  is  used  by  the  HSC  for  determining  funding  allotments  for  Silas  B.  Hays. 
The  information  maintained  in  the  MEPRS  system  is  not  considered  useful  to  the 
department  managers  because  it  is  not  kept  in  a  format  consistent  with  department 
resource  measures. 
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b.      AQCESS 

AQCESS  was  introduced  early  in  1986  for  all  Department  of  Defense 
Hospitals.  The  primary  purpose  of  the  system  was  to  provide  a  standardized  method 
for  the  collection  and  reporting  of  patient  and  provider  information  and  to  assist  in 
quality  assurance  decision  making  for  all  military  hospitals.  AQCESS  was  intended  to 
improve  the  quality  of  the  information  provided  to  administrators,  doctors,  and  quality 
assurance  personnel  and  to  save  hospital  staff  time.  Initially  implemented  with  three 
main  modules,  AQCESS  has  since  been  expanded  to  six  modules.  All  six  modules  are 
in  operation  at  Silas  B.  Hays: 

1.  Quality  Assurance  Module 

2.  Appointment  and  Scheduling  Module 

3.  Medical  Services  Accounts  Module 

4.  Clinical  Records  Module 

5.  Registration  Module 

6.  Emergency  Services  Module 

The  Appointment  and  Scheduling  Module  affects  each  individual 
department  the  most  as  it  determines  the  daily  workload  for  each  doctor  in  the 
department. 

The  AQCESS  system  is  used  to  capacity.  Although  ad  hoc  reports  can 
be  obtained  by  the  users  of  AQCESS,  only  the  system  manager  in  the  Information 
Management  Division  (IMD)  currently  uses  this  function.  The  system  is  heavily  used 
during  normal  working  hours  for  interactive  appointment  scheduling  and  clinical 
records.  To  help  keep  system  response  time  low  during  the  day,  all  AQCESS  reports 
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are  generated  at  night  using  batch  processing.  The  AQCESS  modules  produce  many 
reports  which  show  hospital  operations  and  performance  in  many  areas.  Statistical 
reports  on  workload,  productivity,  and  appointment  scheduling  histories  are  just  a  few 
of  the  topics  covered. 

c.      COSTARS 

The  COSTAR  System  is  unique  to  the  Family  Practice  Clinic  at  Silas 
B.  Hays  Hospital.  This  system  receives,  records,  and  retrieves  administrative  and 
medical  information  for  the  active  duty  families  enrolled  in  the  Family  Practice 
Program  (Libra  Technology,  1982,  p.  2).  This  system  was  actually  a  prototype  system 
introduced  in  1982  and  initially  had  the  five  main  functions  described  below: 

•  Registration  -  This  function  allows  patients  to  be  enrolled  in  the  Family 
Practice  Program. 

•  Appointment  and  Scheduling  -  This  function  allows  the  COSTARS  data  entry 
clerk  to  book,  cancel,  or  view  appointments.  It  also  prints  daily  schedules  and 
appointment  lists  and  produces  a  pull  list  for  the  medical  records  department 
indicating  which  patients  records  will  be  required  for  the  following  day's 
appointments. 

•  Medical  Records  -  This  functions  maintains  a  history  of  a  patient  examination, 
including  administrative,  physical,  diagnostic  and  procedural  data. 

•  Pharmacy  Orders  -  This  function  was  intended  to  provide  full  pharmacy 
support  by  allowing  prescription  orders  to  be  automatically  forwarded  to  the 
pharmacy.  Records  on  pharmaceutical  history  were  also  to  be  kept  for  the 
patients.  Currently,  only  prescription  refills  are  managed  by  this  system. 

•  Laboratory  Orders  -  This  function  permits  physician  orders  for  lab  work  to 
be  automatically  sent  to  the  lab  before  the  patient  arrives.  Results  are  also 
entered  and  a  daily  report  is  sent  to  the  physician  showing  the  patient  and  the 
results  of  the  lab  tests  ordered  for  that  patient. 

Like  AQCESS,  the  COSTARS  system  maintains  a  large  data  base  and 

is  capable  of  producing  many  reports.  COSTARS  also  accepts  ad  hoc  queries  but  none 


29 


are  currently  being  used.  The  pharmacy  and  laboratory  functions  offer  capabilities  not 
found  in  AQCESS.  As  with  the  other  major  systems,  we  believe  this  system  is  not 
being  exploited  to  full  advantage.  This  system,  and  the  potential  benefits  of  the  data 
maintained  within  it,  are  discussed  further  in  subsequent  chapters. 

In  addition  to  the  three  major  information  systems  discussed  above, 
Silas  B.  Hays  makes  extensive  use  of  microcomputers  for  office  automation  and 
individual  data  processing  functions.  These  computers  are  not  currently  networked  nor 
is  there  any  standardization  of  software  or  procedures. 

The  current  information  systems  available  at  Silas  B.  Hays  Hospital 
are  cumbersome  and  cannot  be  integrated  to  provided  timely,  reliable,  and  useful 
information  to  hospital  decision  makers.  The  lack  of  integration  is  seen  as  a  major 
problem  by  many  hospital  personnel  and,  until  the  CHCS  comes  on  line,  stop-gap 
measures  are  being  used  to  fill  the  void  and  provide  the  best  information  available 
with  the  limited  resources. 

The  remainder  of  this  thesis  describes  how  one  department,  the 
Department  of  Family  Practice  and  Community  Medicine  (DFPCM),  uses  the  current 
information  systems  available  at  SBHACH.  Also  examined  is  the  need  for  an  improved 
system  and  how  these  improvements  might  be  realized  through  the  use  of  a  responsive 
microcomputer-based  information  system. 
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III.    CURRENT  SYSTEMS  ANALYSIS 

A.  INTRODUCTION 

Chapter  II  introduced  information  systems  development  methodologies  and  the 
application  of  information  systems  within  a  hospital  environment.  This  chapter 
describes  the  current  information  systems  in  the  Department  of  Family  Practice  and 
Community  Medicine,  using  the  development  principles  discussed  in  Chapter  II.  This 
chapter  introduces  data  flow  diagrams  as  a  pictorial  way  to  represent  the  existing 
information  system  and  presents  data  flow  diagrams  and  narrative  descriptions  for  the 
department's  information  system. 

B.  THE    DEPARTMENT    OF    FAMILY    PRACTICE    AND    COMMUNITY 
MEDICINE 

Early  in  1988,  Health  Services  Command  approved  a  reorganization  for  Silas  B. 

Hays  Hospital  which  combined  the  Department  of  Family  Practice  with  the  Department 

of  Primary  Care  and  Community  Medicine,  creating  the  Department  of  Family  Practice 

and  Community  Medicine  (DFPCM).    This  new  department  is  the  hospitals  largest  and 

most  diverse  in  terms  of  both  the  services  it  provides  and  it's  overall  affect  on  the 

hospital.     Figure  7  is  the  department's  organization  chart.    The  department  has  three 

general  service  areas:    Family  Practice  and  Residency,  Primary  Care,  and  Consolidated 

Troop  and  Family  Member  Services.    These  are  further  divided  into  specialized  clinics 

(sometimes  referred  to  as  sections)  as  shown  in  the  chart.     All  of  these  clinics  are 

outpatient  oriented  and  are  literally  the  gateways  to  all  other  hospital  services  (e.g., 


31 


Deportment  of  Fomily  Practice 

ond  Community  Medicine 


Fomily  Practice 
ond  Residency  Service 

Fomily 

Prcclice 

Clinic 

Resident 
Training 
Progrom 

Primary  Core  Services 


General 

Outpotient 

Clinic 


Fort 
Hunter 
Liggett 
Clinic 


PRIMUS 
Clinic 


Emergency 
Medical 
Services 


Ambulance 
Service 


Consolidated  Troop 
ond  Fomily  Member  Service 

Flight 

Surgeon 

Office 

CTMC 
Troop 
Clinic 

CTMC 
Family 
Practice 

Figure  7.    Organizational  Chart  for  DFPCM 

pharmacy,  lab,  and  specialized  medical  departments).  The  DFPCM  affects  every  aspect 
of  the  hospital:  every  patient  treated  at  Silas  B.  Hays  must  first  be  seen  by  a  doctor 
working  in  one  of  the  DFPCM  clinics.  The  mission  of  the  DFPCM,  as  stated  in  the 
Health  Services  Command  Regulation  10-1,  is  "to  provide  diagnosis,  care,  and  treatment 
of  all  patients  commensurate  with  the  highest  standards  of  quality."  (HSC  Reg  10-1, 
1987,  p.  3-1)  The  task  of  accomplishing  this  mission  is  not  nearly  as  simple  as  the 
mission  statement  itself. 

The  size  of  the  department,  the  volume  of  work  done,  and  the  impact  on  overall 
hospital  resources  combine  to  create  a  highly  visible,  management  challenge.  The 
Chief  of  the  DFPCM  (currently  a  Lieutenant  Colonel)  is  responsible  for  meeting  this 
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challenge.  The  resources  he  commands  include  over  150  people  and  an  annual  budget 
of  nearly  half  a  million  dollars.  In  addition,  there  are  five  separate  service  locations, 
one  of  which  is  100  miles  from  the  main  hospital  (Fort  Hunter  Liggett).  Unfortunately, 
these  resources  are  limited  compared  with  the  task  at  hand.  Since  his  time  is 
extremely  valuable,  the  information  he  gets  should  be  summary  in  nature  in  order  that 
he  not  be  overwhelmed  with  meaningless  data,  and  yet  at  the  same  time,  complete 
enough  to  allow  him  to  make  informed,  confident  decisions.  All  of  these  factors  must 
be  considered  when  designing  an  information  system  for  use  by  the  Chief  of  the 
DFPCM. 

Initial  interviews  with  the  Department  Chief  allowed  us  to  identify  those 
management  areas  which  demand  the  greatest  attention  and  for  which  he  requires  the 
best  possible  information.    These  areas  fell  into  the  following  seven  broad  categories: 

Fiscal  Resources. 

Material  Resources. 

Personnel  and  Scheduling. 

Productivity. 

Patient  Satisfaction. 

Medical  Procedure  Suspense  Information. 

Patient  Check-In  and  Records  Procedures. 

The  last  two  areas  were  determined  to  be  beyond  the  scope  of  this  thesis  because 
of  time  constraints  and  the  inherent  size  and  complexity  of  the  projects  themselves. 
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The  Department  Chief  agreed  with  our  decision  and  prioritized  the  remaining  five  areas 
as  shown  below: 

•  Fiscal  Resources. 

•  Material  Resources. 

•  Personnel  and  Scheduling. 

•  Patient  Satisfaction. 

•  Productivity. 

The  remainder  of  this  thesis  describes  the  research  into  each  of  these  areas  and  the 
requirements  for  an  information  system  which  would  serve  the  Department  Chief  in 
making  management  decisions  concerning  these  key  areas. 

The  five  major  areas  listed  above  were  divided  into  the  following  six  specific 
systems: 

•  Budget  System. 

•  Equipment  System. 

•  Personnel  System. 

•  Scheduling  System. 

•  Patient  Satisfaction  System. 

•  Productivity  System. 

The  following  section  describes  the  six  existing  information  systems  listed  above 
(with  diagrams  and  written  narrative)  and  how  information  is  gathered,  stored,  and 
presented  for  decision  making.  As  described  in  Chapter  II,  the  current  system  should 
be  well  understood  before  any  attempt  is  made  to  improve  any  part  of  it.    Subsequent 
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chapters  discuss  where  and  why  improvements  are  needed  and  how  those  improvements 
can  be  achieved  through  system  redesign  and  automation. 

C.      DATA  FLOW  DIAGRAMS 

In  the  preliminary  description  of  the  information  system  within  the  DFPCM,  we 
used  Data  Flow  Diagrams  (DFDs)  to  represent  the  current  system  to  department 
personnel.  The  Data  Flow  Diagram  enables  the  designer  to  describe  the  existing 
system  or  the  proposed  new  system  at  a  logical  level  without  considering  the  physical 
environment  in  which  the  data  flows  (e.g.,  telephone  calls,  mail,  etc.)  or  the  physical 
environment  in  which  the  data  is  stored  (e.g.,  card  file,  microfiche,  disk,  floppy  disk, 
or  tape).  (Atkas,  1987,  p.  57)  The  DFD  describes  the  system  as  a  network  of 
processes  (subsystems)  connected  to  each  other  and/or  to  data  stores,  sources  and  sinks. 
(Atkas,  1987,  p.  58)    The  basic  symbols  used  in  the  DFD's  are  described  below. 

•  Data  Flow.  An  arrow  is  used  to  represent  either  the  flow  of  information  or 
objects.    Occurrences  of  the  data  flow  must  contain  data. 

•  Process.  A  rounded  rectangle  represents  a  process.  Processes  are  work 
performed  by  people,  machines,  or  computers  on  incoming  data  flows  to 
produce  outgoing  data  flows.  (Whitten,  Bently,  and  Ho,  1986,  p.  226) 

•  External  Entity  or  Boundary.  A  square  is  used  to  represent  an  area  in 
which  data  originates  or  terminates.  In  essence,  the  sources  and  sinks  define 
the  boundaries  of  the  system. 

•  Data  Store.  An  open-ended  rectangle  represents  a  store  of  information  or 
objects,  irrespective  of  the  storage  medium.  (Atkas,  1987,  p.  59) 
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The  components  of  the  information  system  correspond  to  the  DFD  symbols  as  follows 
(Whitten,  Bently,  and  Ho,  1986,  p.  234): 

Information  System  Component  DFD  Symbol 

Data  (Input)  Data  Flow 

Information  (Output)  Data  Flow  Users 

Entity/Process  Methods/Procedures 

Process  Data  Storage  Data  Store 

Computer  Equipment  Process/Data  Store 

Computer  Programs  Process 

To  achieve  clarity,  DFD's  are  prepared  at  several  levels.  The  highest  level  DFD 
is  the  "context  diagram,"  which  merely  shows  the  boundaries  of  the  system  under 
study.  The  processes  are  further  decomposed  as  necessary  into  lower  level  diagrams. 
(Atkas,  1987,  p.  68).  The  following  sections  use  DFD's  to  illustrate  the  six  current 
information  systems. 

1.      Budget  System  (see  DFD,  Figure  8). 

The  Resource  Management  Division  (RMD)  receives  the  hospital's  budget 
from  the  Health  Services  Command  on  an  annual  basis  via  the  MED  304  report. 
RMD  divides  this  budget  into  quarterly  budget  targets  for  each  department  and 
distributes  the  budget  allocations  at  the  beginning  of  each  quarter.  The  department 
Non-commissioned  Officer  in  Charge  (NCOIC)  (currently  a  Master  Sergeant)  is  the 
principle  administrator  of  all  incoming  budgetary  information.  He  serves  both  as  the 
Department  Chief's  budget  administrator  and  the  clinics  central  point  of  contact  on  all 
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budgetary  matters.     This  practice  of  using  the  NCOIC  as  the  monitor  appears  to  be 

common  practice  throughout  the  hospital. 

Once  the  department's  budget  is  received  from  RMD  it  is  allocated  by  the 

NCOIC   into    16   separate   accounts.      The    16   budget   accounts   reflect   the   current 

organizational  structure  with  a  few  exceptions  required  by  funding  needs.     The  16 

sections  are  listed  below: 

Primary  Care.  This  is  an  overall  budget  category  for  any  department  wide 
requirements. 

Family  Practice  Clinic.  This  is  the  eighth  floor  Family  Practice  clinic  at  the 
hospital. 

CTMC-Family  Practice.  This  is  the  Family  Practice  clinic  operated  at  the 
CTMC. 

Emergency  Medical  Services.  This  is  the  emergency  room  excluding  the 
ambulance  section  requirements. 

Ambulance  Section.  Supply  budget  for  the  ambulance  section  which  is  a 
subsection  of  the  emergency  room. 

Flight  Surgeon  Office. 

General  Outpatient  Clinic.  Serves  walk-in  patients  and  active  duty  sick  call 
in  the  Hospital. 

Presidio  of  Monterey-Health  Clinic.  Though  the  POM  clinic  is  run  by 
PRIMUS,  the  department  assigns  a  doctor  as  liaison  to  handle  sickcall  and 
official  military  matters  for  which  it  receives  department  funds. 

Consolidated  Troop  Medical  Clinic  (CTMC).  Medical  care  for  7th  Light 
Infantry  Division  personnel. 

Battalion  Aid  Station.  This  money  is  provided  to  the  Division  Medical 
Supply  Office  to  reimburse  medical  supplies  used  by  the  battalion  aid  stations 
throughout  the  division. 

Fort  Hunter  Liggett  Clinic. 
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•  CTMC  (Pathology).    Funds  in  this  category  pay  for  supplies  needed  by  the 
pathology  section  located  at  the  CTMC. 

•  CTMC  (Radiology).    Funds  in  this  category  pay  for  supplies  needed  by  the 
X-Ray  section  at  the  CTMC. 

•  CTMC  (Pharmacy).    Funds  in  this  category  pay  for  supplies  needed  by  the 
Pharmacy  Section  at  the  CTMC. 

•  CTMC    (Immunization).      Funds   in  this   category  pay   for  immunization 
supplies  for  the  CTMC. 

•  Battalion    Aid    Station    (Immunization).      Funds   in  this  category  pay   for 
immunization  supplies  used  by  the  battalion  aid  stations. 

Each  section  prepares  requisitions  and  monitors  its  expenditures  in  its  own 

Document  Control/Funds  Control  register  (DC/FC).    This  document  serves  as  a  record 

for  items  ordered  and  an  indicator  of  the  account's  remaining  funds  once  the  supplies 

are  received.     The  DC/FC  register  is  currently  maintained  manually  in  each  clinic's 

supply  section.    One  important  location  for  the  expenditure  of  supply  dollars  is  the  Self 

Service  Supply  Center  (SSSC).    The  SSSC  is  a  self  service  supply  point  for  certain 

office,   medical    and   computer   supplies.      These   supplies    are    charged    against   the 

individual  section's  account  and  are  usually  recorded  on  a  weekly  recap  basis  by  an 

entry  into  the  DC/FC  register.    These  expenditures  are  reconciled  on  a  weekly  basis 

with  the  Detailed  Obligation  Report  (DOR).    This  report  confirms  correct  obligation 

amounts  and  recorded  orders.    Four  copies  of  the  DOR  are  received  weekly  from  RMD 

in  microfiche  form.    The  four  copies  are  distributed  to  the  CTMC,  Fort  Hunter  Liggett 

clinic,  the  main  Family  Practice  clinic,  and  the  department  NCOIC.     There  are  a 

limited  amount  of  DOR's  available,  so  every  section  cannot  receive  it's  own  copy. 

This  shortage  is  caused  by  a  number  of  microfiches  actually  delivered  to  RMD. 
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Figure  8.    Budget  System  Data  Flow  Diagram 

The  NCOIC  provides  the  Department  Chief  with  budget  information  via 
the  department  Budget  Status  Report  (see  Figure  9).  This  report  is  prepared  at  the 
beginning  of  the  quarter,  at  the  beginning  of  each  month,  and  on  a  recap  basis  at  the 
end  of  each  quarter  and  the  Fiscal  Year.  The  Budget  Status  Report  is  the  department's 
principle  source  of  information  on  current  budget  and  expenditure  status  for  each  of 
the  16  accounts.  The  report  is  currently  generated  using  a  LOTUS  1-2-3  spreadsheet 
program  maintained  by  the  NCOIC.    The  spreadsheet  printout  shows  expenditures  by 
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Figure  9.    Department  Budget  Status  Report 
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section,  their  uncommitted  funds  and  appropriate  percentages  of  expenditures  for  the 
reporting  period.  The  printout  is  given  to  the  Chief  monthly  and  maintained  by  the 
NCOIC  in  a  file  on  a  microcomputer  disk. 

Monthly,  the  NCOIC  receives  a  month-end  report  from  RMD  that  reflects 
the  expenditures  by  medical  and  non-medical  categories  for  each  of  his  separate  clinics. 
The  month-end  report  is  used  to  update  the  Budget  Status  Report  for  review  by  the 
Department  Chief  and  the  section  chiefs.  The  principle  problem  with  this  system 
concerns  the  end  of  year  constraints.  As  the  end  of  the  year  approaches,  the 
expenditure  of  funds  becomes  crucial.  The  amount  that  is  reflected  in  the  month-end 
report  may  be  several  obligations  behind  the  actual  expenditures  recorded  in  the 
section's  DC/FC  register.  This  requires  a  direct  matching  of  available  funds  by 
monitoring  the  sections  through  telephonic  expenditure  reports. 

Quarterly,  the  Resource  Information  Report  is  generated  to  be  used  in  a 
meeting  between  the  Department  Chief  and  his  section  chiefs  (see  Figure  10).  This 
report  serves  as  the  agenda  for  the  meeting.  The  primary  topic  in  this  meeting  is  the 
projected  budget  shortfalls  for  the  quarter  based  on  unforeseen  requirements. 

On  an  as  needed  basis,  the  Budget  and  Equipment  Analysis  and  Review 
report  (the  BEAR)  is  requested  from  the  section  chiefs.  This  report  reflects  much  the 
same  budget  information  contained  in  the  Resource  Information  Report  but  includes 
important  information  on  the  status  of  critical  department  equipment  such  as 
replacement  or  maintenance  requirements  (discussed  below).  The  BEAR  is  collected 
by  the  NCOIC  for  comments  and  delivered  to  the  Chief  for  his  review. 
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Figure  10.    Resource  Information  Report  (RIR) 
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2.      Equipment  Procurement  System  (see  DFD,  Figure  11). 

The  equipment  requirements  for  the  department  are  interrelated  with  the 
budget  system  described  above  in  that  all  expenditures  for  equipment  must  be  budgeted 
and  tracked  within  that  system.  The  department's  equipment  needs  occur  in  the  four 
areas  listed  below: 

•  Durable  Equipment.  This  includes  low  cost,  less  than  $1000,  equipment  that 
is  used  on  a  day  to  day  basis.  This  equipment  is  funded  through  the  normal 
supply  budget. 

•  Capital  Expense  Equipment  Program  (CEEP).  Medical  equipment  that 
costs  more  than  $1000  but  less  than  $5000.  The  budget  for  this  equipment 
is  maintained  by  RMD. 

•  Medical  Care  Support  Equipment  (MEDCASE).  Equipment  that  costs  more 
than  $5000.    This  budget  is  maintained  by  RMD. 

•  Computer/Electronic  Equipment.  Although  the  cost  of  this  equipment  is 
taken  out  of  the  department's  budget,  the  approval  to  order  it  comes  from 
outside  the  department  (discussed  below). 

The  primary   source   of  equipment   authorizations   is  the  Table   of  Distribution   and 

Allowances  (TDA)  which  shows  the  equipment  authorized  to  be  procured  and  held  by 

each  department  section.    Special  medical  equipment  not  included  in  the  TDA  must  be 

specifically  identified  and  requested  by  the  department. 

Each  section  identify  their  equipment  requirements  by  determining  equipment 

authorization  levels,  the  equipment  currently  on  hand,  the  status  of  equipment  on  order, 

and  the  equipment  that  requires  replacement.   The  sections  have  numerous  sources  they 

can  use  to  determine  the  status  of  their  equipment     The  logistics  Division's  Property 

Management  Branch  maintains  property  records  for  all  equipment  held  by  each  section. 

They  also  produce  reports  on  the  stanis  of  equipment  on  order,  the  useful  life  of 
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equipment  on  hand,  and  the  number  of  years  the  equipment  has  been  extended  over  its 
defined  useful  life.  The  Medical  Maintenance  Division  maintains  cumulative  status 
reports  on  the  maintenance  performed  on  all  medical  equipment  along  with  the  one- 
time expenditure  limit  which  defines  the  maximum  limit  for  future  repair  costs  for  each 
equipment  item.  This  information  is  critical  in  determining  if  a  piece  of  equipment  has 
exceeded  its  allowed  maintenance  expense. 

The  problem  with  all  of  these  reports  is  their  relative  inaccessibility  to  the 
sections.  The  reports  are  not  distributed  to  the  sections  and  the  maintenance  reports 
are  maintained  in  the  Medical  Maintenance  building,  separate  from  the  hospital. 
Because  of  these  difficulties,  not  all  sections  attempt  to  obtain  this  information. 
Another  major  factor  affecting  the  availability  of  this  information  is  that  the  reports  are 
not  divided  into  sections  or  departments  but  maintained  on  a  hospital-wide  basis. 

Often,  equipment  needs  are  not  identified  until  failure  of  the  old  equipment. 
The  Department  Chief  and  NCOIC  recently  created  the  Budget  and  Equipment  Analysis 
Report  (BEAR)  to  help  them  plan  for  equipment  expenditures  and  better  manage  their 
equipment  budget  (see  Figure  12).  This  report  will  be  completed  by  each  section  on 
an  annual  basis  to  identify  critical  equipment  needs.  The  BEAR  report  not  only 
identifies  critical  needs  but  was  intended  to  promote  interest  in  identifying  those  needs 
in  a  more  timely  manner.  The  sections  must  identify  their  replacement  requirements 
for  the  upcoming  fiscal  year  and  for  four  subsequent  years,  he  sections  also  report  the 
requirements  for  CEEP  and  MEDCASE  items,  along  with  the  stams  of  equipment  on 
order. 
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Figure  11.    Equipment  System  Data  Flow  Diagram 

Once  the  section's  requirements  are  identified  with  the  BEAR,  the 
Department  Chief,  in  conjunction  with  his  service  chiefs,  determines  the  priorities  for 
the  department.  The  appropriate  paperwork  is  completed  and  forwarded  to  the  RMD 
Logistics  Division  to  await  the  next  hospital  wide  Program  and  Budgeting  Advisory 
Committee  (PBAC).  The  PBAC  consists  of  key  hospital  personnel  who  review  and 
prioritize  MEDCASE  and  CEEP  requirements  for  each  department.  If  approved,  these 
items  go  onto  a  list  of  prioritized  and  approved  equipment,  either  MEDCASE  or  CEEP, 
and  await  the  availability  of  funds. 
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Figure  12.    Budget  and  Equipment  Analysis  Report  (BEAR) 
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Currently,  there  is  no  consolidated  list  of  the  department's  needs  but  each 
section  maintains  its  own  list.  The  only  source  of  consolidated  information  on 
equipment  needs  are  the  quarterly  Resource  Information  Reports,  discussed  in  the 
previous  section. 

Needs  for  electronic  and  communications  equipment  are  separately  identified 
by  each  section  on  an  Information  Capability  Request  (CAPR).  Once  the  CAPRs  are 
approved  by  the  Department  Chief,  they  must  be  countersigned  by  the  Chief, 
Information  Management  Division,  the  Deputy  Commander  for  Clinical  Services,  and 
eventually  by  the  Directorate  of  Information  Management  for  Fort  Ord  (DOIM).  Once 
approved,  it  is  the  responsibility  of  the  department  to  obtain  the  funds  and  order  the 
equipment. 

The  Department  Chief  needs  all  of  this  information  to  plan  for  equipment 
expenditures.  He  can  use  the  information  provided  by  his  sections  to  plead  his  case 
to  the  hospital  administrators  who  allocate  the  funding  dollars  for  his  department.  The 
"out  year"  information  provides  him  with  a  projection  of  future  equipment  needs  and 
helps  improve  the  department  budgets. 

3.      Personnel  System  (see  DFDs,  Figures  13  and  14) 

The  DFPCM  employs  more  than  150  people.  To  effectively  manage  these 
people,  the  Department  Chief  requires  personnel  information  in  three  main  areas: 
authorized  positions  and  vacancies,  educational  travel  funding  requirements,  and 
personnel  leave  and  temporary  duty  requests. 
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Each  department  in  the  hospital  is  authorized  a  certain  number  of  people, 
by  position,  based  on  the  Table  of  Distribution  and  Allowances  (TDA).  The 
Department  NCOIC  uses  a  word  processing  program  to  keep  a  list  of  all  authorized 
positions,  both  filled  and  vacant,  for  the  DFPCM.  This  list  contains  appropriate  TDA 
line  numbers  and  position  descriptions  plus  the  personal  data  for  all  assigned  persons 
(or  a  "vacant"  indication  if  the  position  is  unfilled).  On  an  as-needed  basis,  the 
NCOIC  prints  the  personnel  position  list  for  each  section.  Each  section  NCOIC,  if 
necessary,  updates  his  list  and  returns  it  to  the  Department  NCOIC  who  then  updates 
the  master  roster.  The  updated  master  roster  is  forwarded  to  the  Department  Chief  and 
is  also  sent  to  the  MEPRS  section  to  update  their  Position  Control  Roster. 


'  PREPARE  \ 

UPDATES  FOR 

PERSONNEL 

LISTING 


(UPDATED  PERSONNEL  MET) 


PARE  HEl)i 
PERSONNEL    (PERSONNEL  CHANGES) 
ROSTER  lt 


(PERSOMHEL  CHANGES  > 


(CURRENT  POSITIONS) 


PERSONNEL 
ROSTER 


DEPARTHENT 
NCOIC 


TABU  OF 
DISTRIBUTION 

ALLOWANCES 


KAUTH  POSITIONS/ 


'  IFDATE 
PERSONNEL 
ROSTER 


UCAPERS 

POSITION 

CONTROL  ROSTER 


(CURRENT  POSITIONS) 


:LfDATED  POSITIONS) 


(POSITION  CHANGES) 


CIVILIAN 

PERSONNEL 
OFFICE 


I  PREPARE 
POSITION 
tFDATES 


S 


(AUTHORIZED  CHANGES:' 


Figure  13.    Personnel  System  Data  Flow  Diagram 
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Figure  14.    Leave  and  TDY  Absence  Data  Flow  Diagram 

The  Continuing  Medical  Education  (CME)  program  provides  the  doctors 
within  the  hospital  the  necessary  funds  for  continuing  their  medical  education.  Each 
doctor  determines  his  or  her  educational  needs  and  prepares  a  CME  request  which 
includes  the  estimated  cost  of  travel.  These  requests  are  reconciled  with  the 
department's  allocated  CME  funds  and  if  sufficient  funds  are  available,  the  request  is 
approved  by  the  Department  Chief  and  forwarded  to  the  Deputy  Commander  for 
Clinical  Support  (DCCS)  for  approval.  The  DCCS  publishes  a  master  list  of  doctors 
approved  for  CME  travel.    The  NCOIC  requires  each  doctor  who  has  completed  his 
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or  her  CME  travel  to  provide  a  copy  of  the  travel  claim  voucher.  Through  this 
information,  the  NCOIC  can  capture  actual  CME  costs  well  before  they  are  reported 
by  the  travel  personnel  at  finance  (which  can  be  one  to  three  months  after  the  travel). 
The  CME  funds  are  managed  closely  because  actual  costs  often  exceed  the  estimates 
originally  stated  in  the  request.  The  CME  funds  are  maintained  separately  from  supply 
funds. 

The  Department  Chief  expressed  a  desire  to  monitor  leave  and  temporary 
duty  (TDY)  status.  Leave  and  TDY  information  is  collected  in  two  separate  methods 
depending  on  the  person  involved  (see  Figure  14).  Doctors  send  leave  and  TDY 
requests  to  the  Department  Chief,  via  their  chain  of  command.  Requests  approved  by 
the  Chief  are  recorded  in  a  journal  kept  by  the  department  administration  section  and 
forwarded  to  the  DCCS.  The  doctor  must  also  notify  the  Assistant  Department  Chief 
(ADC)  of  any  planned  absences  for  scheduling  purposes  (see  Figure  9,  Scheduling). 
The  hospital  Personnel  Administration  Center  (PAC)  types  approved  requests  on  a 
Department  of  the  Army  (DA)  Form  31.  This  form  is  routed  through  the  hospital 
distribution  system  to  the  NCOIC  who  distributes  it  to  the  doctor's  respective  section. 
Other  personnel  leave  and  TDY  requests  are  routed  through  the  Medical  Company 
chain  of  command.  After  approval  by  the  Medical  Company  First  Sergeant  and 
Commander,  these  requests  are  forwarded  to  the  PAC,  typed  on  a  DA  Form  31,  and 
distributed  via  the  department  NCOIC  to  the  appropriate  section. 

The  Department  Chief's  main  concern  in  managing  personnel  is  planning  for 
position  vacancies  and  temporary  absences  due  to  leave  and  TDY.  Presently,  section 
chiefs  report  upcoming  losses  on  an  exception  basis  only,  primarily  when  the  position 
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involved  is  critical  to  section  operations.  The  PAC  has  the  capability  to  report  military 
personnel  losses  on  a  30,  60,  90,  120,  150,  180,  270,  and  300  day  basis,  but  this 
information  is  available  only  on  a  hospital-wide  basis. 

4.      Scheduling  System  (see  DFDs,  Figures  15  and  16) 

The  Department  Chief's  primary  concern  for  scheduling  lies  in  two  clinics, 
the  Family  Practice  clinic  and  the  CTMC/FP  clinic.     Figures  15  and   16  show  the 
doctor  scheduling  process  as  it  currently  exists  in  each  of  these  clinics,  respectively. 
a.      Family  Practice  Scheduling 

The  Family  Practice  scheduling  system  involves  two  primary  schedules, 
the  On-Call  Schedule  and  the  Clinic  Schedule,  and  a  secondary  schedule,  the  Walk-In 
Schedule.  The  Assistant  Department  Chief  (ADC)  creates  each  of  these  schedules. 
This  process  is  very  subjective  and  difficult  to  define  precisely.  Each  of  the  following 
sections  describes  the  process  for  each  of  the  schedules  discussed  above. 

(1)  On-Call  Schedule.  The  On-Call  Schedule  establishes  which  doctor 
will  be  on-call  for  each  night  of  the  month.  The  On-Call  Schedule  affects  every  clinic 
within  the  department  except  the  Emergency  Medical  Services  which  have  their  own 
on-call  schedule.  To  create  this  schedule,  the  Assistant  Department  Chief  (ADC) 
maintains  several  different  files  which  help  him  determine  which  doctor  to  schedule  for 
each  day. 

Every  clinic  has  a  minimum  number  of  doctors  which  are  required 
to  be  on  duty  each  day.  This  information  is  maintained  on  a  sheet  of  paper  in  the 
ADC's  scheduling  folder  and  is  necessary  for  creating  the  On-Call  Schedule  because 
a  doctor  who  is  on-call  one  day  will  not  be  available  for  duty  the  following  day.    The 
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ADC  also  maintains  historical  data  for  each  doctor  showing  the  number  of  times  the 
doctor  has  been  on  call  on  holidays  and  weekends.  The  ADC  keeps  3"  x  5"  cards 
with  special  requirements  for  each  doctor  such  as  continuing  education,  or  conference 
dates  for  which  the  doctor  would  be  unavailable  for  on-call  duty.  The  doctors  must 
also  inform  the  ADC  when  they  are  requesting  leave  or  when  they  will  be  away  on 
temporary  duty  (TDY).  The  last  information  kept  by  the  ADC  is  a  cumulative 
monthly  tally  of  the  number  of  times  each  doctor  has  stood  on-call  duty  for  the  last 
calendar  year.  After  considering  all  of  this  information,  the  ADC  creates  the  On-Call 
Schedule  in  a  manner  which  will  be  fair  to  all  of  the  doctors  and  yet  fill  the 
requirements  for  on-call  duty  and  the  following  day's  clinic  schedule.  The  on-call 
schedule  is  distributed  to  each  doctor,  the  patient  care  nursing  stations  on  each  ward, 
the  emergency  room,  and  the  Clinical  Support  Division.  In  addition,  the  on-call 
schedule  is  used  to  create  the  clinic  schedule  for  the  Family  Practice  doctors. 

(2)  Clinic  and  Walk-In  Schedules.  As  with  the  on-call  schedule,  the 
clinic  schedule  is  created  by  the  ADC  after  considering  all  of  the  information  relating 
to  doctor  availability.  Staff  doctors  have  a  permanent  clinic  schedule  for  each  month. 
This  is  affected  only  by  leave  requests  and  TDY  orders  from  the  doctors  themselves. 
The  ADC  must  also  schedule  residents-in-training  for  clinic  duty.  Each  resident  is 
assigned  a  primary  location  for  each  month  by  the  Resident  Director.  The  ADC  keeps 
this  information  in  his  scheduling  folder  along  with  special  instnictions  for  each 
resident  from  his  assigned  clinic.  These  instnictions,  on  3"  x  5"  cards,  contain 
information  on  the  daily  availability  of  the  resident  for  duty  in  the  Family  Practice 
clinic.    Also  affecting  the  clinic  schedule  is  the  previous  day's  on-call  schedule:    the 
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doctor  who  was  on  call  the  previous  day  will  not  be  available  for  work  in  the  clinic 
on  the  day  in  question.  The  ADC  creates  the  clinic  schedule  based  on  the  number  of 
doctors  available  for  each  day  of  the  month.  The  final  clinic  schedule  is  submitted  to 
the  COSTARS  data  entry  clerk  so  the  appointment  system  can  be  updated  to  show 
which  doctors  will  be  available  to  see  patients  in  the  scheduled  month.  Also,  for  each 
day  on  the  clinic  schedule,  the  ADC  schedules  one  doctor  to  see  walk-in  patients. 
This  doctor  is  then  responsible,  on  the  day  assigned,  to  see  all  family  practice  patients 
who  could  not  get  an  appointment  but  required  immediate  care.  The  walk-in  schedule 
is  attached  to  the  final  clinic  schedule  and  distributed  to  each  doctor. 


I  W  CALL  SOCDULE 


Figure  15.    Family  Practice  Scheduling  Data  Row  Diagram 
b.      CTMC/FP  Clinic  Schedule 

The  Chief  of  the  CTMC/FP  clinic  completes  his  clinic  schedule  in 
much  the  same  manner  as  described  for  the  family  practice  clinic.      The  on-call 
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schedule  created  by  the  ADC  includes  CTMC/FP  doctors  and  therefore  impacts  the 
CTMC/FP  daily  clinic  schedule.  The  Chief  of  CTMC/FP  uses  the  previous  day's  on- 
call  schedule  to  determine  which  doctor  will  not  be  available  for  duty  on  the  current 
day.  Additionally,  he  receives  each  of  the  CTMC/FP  doctors  leave  and  TDY  requests 
and  special  availability  requirements  which  he  maintains  in  one  log  book.  He  consults 
this  log  book  and  the  on-call  schedule  for  the  upcoming  month  to  create  the  CTMC/FP 
schedule  for  that  month.  He  distributes  this  schedule  to  each  doctor  and  one  copy  is 
sent  to  the  AQCESS  data  entry  clerk  who  updates  the  appointment  scheduling  database 
to  reflect  the  doctors  available  for  appointments  in  the  CTMC/FP  clinic  for  the 
upcoming  month. 

As  can  be  seen  from  the  previous  discussion,  the  scheduling  process 
is  subjective  and  dependent  on  the  historical  files  and  log  books  maintained  by  the 
clinic  schedulers.  The  most  difficult  part  of  this  process  is  obtaining  and  coordinating 
all  of  the  information  sources  which  affects  the  doctors'  availability  for  duty  on  any 
given  day  of  the  month.  The  ADC  estimated  that  it  required  3  to  4  hours  to  create 
the  monthly  schedules  because  of  the  many  factors  influencing  the  entire  process. 


DOCTOR 


<LEAVE/TDY  REQ> 


FAMILY     <0N  CALL  SCHEDULE) 

PRACTICE  ON   

CALL  SCHEDULE 


\1 


<CTMC/FP  SCHEDULE) 


AQCESS 
CLERK- 


DOCTOR     (SPECIAL  AVAIL  REQ)    /  CREATE 

AVAILABILITY   — »  CTMC/FP  CL 

LOG  BOOK.  \  SCHEDULE 


J 


<CTMC/FP  SCHEDULE) 


Figure  16.    CTMC/FP  Scheduling  Data  Flow  Diagram 
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5.       Patient  Satisfaction  (see  DFD,  Figure  17) 

Determining  patient  satisfaction  is  a  subjective  process  and  is  currently 
performed  by  the  department's  quality  assurance  representative.  The  QA  representative 
created  a  questionnaire  to  obtain  subjective  responses  from  patients  on  various  topics. 
The  patients  are  asked  to  respond  "Yes",  "No",  or  "Not  Applicable"  to  eleven  questions 
concerning  the  care  they  received  in  the  Family  Practice  clinic.  This  is  the  only  clinic 
currently  using  the  patient  satisfaction  survey. 
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Figure  17.  Patient  Satisfaction  Data  Flow  Diagram 

On  one  day  of  each  month,  the  doctors  in  the  FP  clinic  are  asked  to 
distribute  the  questionnaires  to  the  patients  they  see,  with  instructions  that  the  patient 
return  the  surveys  to  the  receptionist  at  the  nurses  station.    The  receptionist  gives  all 
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of  the  collected  surveys  to  the  QA  representative  who  then  calculates  the  percentage 
responses  for  each  of  the  questions  and  produces  Monitor  and  Evaluation  Reports. 

Each  Monitor  and  Evaluation  (M&E)  report  prepared  by  the  department 
QA  representative  represents  an  important  aspect  of  care  recognized  by  the  hospital  QA 
Division  (see  example,  Figure  18).  Each  question  in  the  survey  is  an  indicator  of  one 
of  these  important  aspects  of  care.  Each  question  (indicator)  has  an  assigned  threshold 
(listed  on  the  M&E  report)  which  the  clinic  desires  to  remain  above.  When  the  results 
of  the  survey  are  tallied,  the  QA  representative  pencils  in  the  patient  response  rate  for 
each  question  next  to  the  corresponding  threshold  on  the  M&E  report.  The  completed 
Monitor  and  Evaluation  report's  are  used  as  an  indicator  of  how  successful  the 
department  was  in  reaching  the  thresholds  for  each  of  the  important  aspects  of  care. 

These  Monitor  and  Evaluation  reports  are  maintained  in  a  binder  kept 
by  the  QA  representative  and  are  used  at  the  monthly  QA  meetings  to  report  on  the 
general  level  of  patient  satisfaction  for  each  of  the  important  aspects  of  care.  No  other 
reports  are  created  using  the  information  obtained  from  the  questionnaires  and  trends 
in  patient  responses  are  not  maintained.  The  Department  Chief  does  not  receive  a 
copy  of  the  Monitor  and  Evaluation  reports  unless  he  requests  them. 
6.      Productivity  (see  DFD,  Figure  19) 

The  DFD  in  Figure  19  depicts  the  current  information  processes 
involved  in  reporting  productivity  for  the  DFPCM.  The  CTMC/FP  section  is  the  only 
section  reporting  productivity  to  the  Department  Chief.  The  primary  reason  for  this  is 
the  fact  that  the  CTMC  is  an  ancillary  service  specially  monitored  by  the  Clinical 
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MONITOR  &  EVALUATION 


SCOPE   Patient  satisfaction 

IMPORTANT  ASPECT  OF  CARE:  patients  will  be  treated  courteously  and 
professionally  by  the  staff. 


THRESHOLD 
INDICATORS: 

1)  Survey  indicates  records  ready  at  the  front  desk 

2)  Survey  indicates  screening    prompt  and  private  901 

3)  Survey  indicates  waiting  time  will  be  30  mm  or  less  90* 


,1/v?      90  I 


SOURCE  OF  DATA:  patients'  survey 

♦ 

METHOD  OF  COLLECTION:  Family  practice  receptions  clerk  provides 
patients  witb  survey  to  be  completed  after  appoinmenl. 

WHO  TO  COLLECT  DATA:  Receptions  clerk  to  forward  to  nurse  or  QA 
coordinator 

SAMPLE  SIZE  30 

TIME  FRAME:  One  day  per  month,  every  other  month  starting  witb 
August88 

Figure  18.    Monitor  and  Evaluation  Report 

Support  Division.    The  CTMC/FP  appointments  and  patient  visits  are  tracked  by  the 

AQCESS  system. 

The  AQCESS  system  produces  a  report  called  the  Validated 
Appointment  Roster  which  shows  the  actual  patients  seen  the  previous  day.  This  report 
is  sent  to  the  Clinical  Support  Division  which  counts  the  number  of  patients  actually 
seen  by  the  CTMC,  per  provider.  A  cumulative  total  is  kept  for  the  entire  month.  At 
the  end  of  the  month,  the  Clinical  Support  Division  enters  this  information  into  a 
LOTUS  1-2-3  spreadsheet.     The  resulting  productivity  reports  are  sent  to  the  Chief, 
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DFPCM.  These  reports  provide  information  on  daily,  weekly,  monthly,  quarterly,  and 
yearly  workload  in  tabular  and  graphical  formats.  Provider  productivity  is  also  reported 
in  a  tabular  report  showing  the  number  of  patients  seen  each  day,  by  provider,  for  the 
reported  month. 

Although  the  productivity  of  all  of  the  sections  is  not  directly  reported 
to  the  Chief,  the  data  necessary  for  producing  clinical  productivity  information  is 
gathered  by  each  section.  The  remaining  sections  use  either  AQCESS,  COSTARS  or 
manual  logs  for  gathering  workload  data.  Patient  visit  information  is  then  reported  to 
the  Patient  Administration  Division  (PAD).  PAD  collects  and  forwards  all  hospital 
workload  information  to  the  Health  Services  Command  on  the  MED  302  report  both 
electronically  and  in  paper  format.  This  report  is  used  in  the  formulation  of  future 
budgetary  allocations  to  the  hospital.  Figure  20  illustrates  how  the  various  department 
clinics  currently  input  their  workload  information  to  PAD.  All  of  the  workload  data 
collected  by  the  department's  various  sections  is  also  stratified  according  to  patient 
demographics,  e.g.,  active  duty,  dependents,  retired,  service,  etc. 
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Figure  19.    Productivity  System  Data  Flow  Diagram 
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The  Department  Chief  wants  productivity  information  for  all  of  his 
clinics,  similar  to  that  provided  to  him  by  the  Clinical  Support  Division  for  the 
CTMC/FP  clinic.  The  raw  data  for  creating  most  of  this  information  exists  in  the 
current  systems  but  is  not  being  used  because  of  time  and  personnel  constraints,  and 
other  factors  which  were  not  readily  identifiable. 
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Figure  20.    Clinic  Workload  Data  Flow  Diagram 


59 


IV.  FUNCTIONAL  SPECIFICATIONS 

A.  INTRODUCTION 

Chapter  HI  presented  the  DFPCM's  current  information  systems  relating  to  six 
specific  areas:  budget,  equipment  procurement,  personnel,  scheduling,  patient 
satisfaction,  and  productivity.  This  chapter  summarizes  the  current  system's 
deficiencies  and  examines  the  failure  of  automation  to  meet  the  department's 
information  requirements. 

Additionally,  this  chapter  proposes  general  improvements  for  each  of  the  six 
areas  and  discusses  the  impact  of  these  solutions,  and  the  impact  of  automation  on  the 
department's  information  systems.  The  detailed  system  improvements  for  each  of  the 
information  systems  are  presented  fully  in  Chapter  V,  Requirements  Analysis. 

B.  CURRENT  INFORMATION  SYSTEM  DEFICIENCIES 

The  Chief  of  the  DFPCM  makes  many  decisions  which  affect  both  his  personnel 
and  resources,  and  greatly  impacts  the  entire  hospital.  The  nature  of  his  responsibilities 
and  the  span  of  control  he  is  required  to  exercise  place  additional  emphasis  on  the 
significance  of  these  decisions.  Facing  both  time  constraints  and  limited  resources,  he 
needs  the  right  information,  at  the  right  time,  and  in  the  best  format  to  accomplish  his 
objectives  and  meet  the  needs  of  the  department  and  the  hospital.  In  analyzing  the 
existing  department  information  system,  we  discovered  many  deficiencies  which  hinder 
the  Department  Chief's  ability  to  make  informed  decisions. 
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In  general,  the  reports  and  other  information  the  Department  Chief  receives  are 
complex  and  difficult  to  quickly  comprehend  because  they  are  not  summary  in  nature. 
In  interviews  with  the  Department  Chief,  he  expressed  a  desire  for  information  which 
would  depict  long  term  trends  and  show  department  performance  over  a  predetermined 
period  of  time.  Much  of  the  information  he  gets  now  is  a  "snap-shot"  in  time  which 
does  not  allow  him  to  see  the  "bigger  picture"  without  pouring  through  many  similar 
reports.  In  a  few  cases,  the  data  is  simply  too  time  consuming  to  analyze  (e.g., 
budget,  equipment  and  personnel  information)  and,  therefore,  never  becomes  meaningful 
information  for  the  Department  Chief. 

In  addition  to  poor  information,  the  Department  Chief  occasionally  has  difficulty 
getting  enough  information.  One  of  the  Department  Chief's  concerns  is  having  sound 
information  to  help  justify  his  decisions  to  higher  authorities  and  support  his  actions 
in  managing  resources  and  personnel.  Missing  information  due  to  informal  reporting 
standards  or  poor  data  collection  impedes  his  decision  abilities  in  these  areas. 

Another  concern  of  the  Department  Chief  is  the  importance  of  feedback.  The 
Department  Chief  feels  it  is  critical  for  each  section  to  receive  sufficient,  and  timely, 
feedback  on  their  performance  to  allow  them  to  become  more  effective  and  efficient 
on  there  own  initiative.  The  sections  currently  receive  very  little  in  the  way  of 
constructive  feedback  and  the  information  they  do  get  is  prone  to  the  same  problems 
discussed  above. 

Unfortunately,  inconsistent  reporting  requirements  and  system  capabilities  exist 
throughout  the  department  so  that  each  section  is  substantially  different  from  the  others 
in  the  information  it  is  able  to  report.     This  contributes  to  many  of  the  problems 
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described  in  the  preceding  paragraphs.  Succinctly,  the  current  information  system  is 
not  meeting  the  requirements  of  the  Department  Chief.  We  feel  the  majority  of  these 
obstacles  can  be  attributed  to  limited  personnel  resources,  time  constraints,  and 
ultimately,  the  incompatibility  of  the  hospital's  automated  information  systems. 

C.  THE  FAILURE  OF  AUTOMATION  TO  MEET  INFORMATION 
REQUIREMENTS 

Chapter  II  introduced  the  three  major  automated  information  systems  in  place  in 
the  hospital:  MEPRS,  AQCESS,  and  COSTARS.  These  systems  hold  huge  stores  of 
data  which  can  potentially  produce  meaningful  information.  In  addition  to  these 
medical  information  systems,  the  hospital  uses  other  Army-wide  systems  for  accounting 
and  logistical  data.  Microcomputers  are  scattered  throughout  the  hospital  providing 
individual  computing  capabilities  in  some  functional  areas.  With  all  of  these  resources 
at  hand  and  with  the  rapid  advance  in  information  systems  technology,  the  question 
arises,  "Why  hasn't  automation  solved  the  information  problems  within  the  DFPCM?" 

There  are  many  reasons  why  the  automated  systems  at  Silas  B.  Hays  have  failed 
to  meet  the  information  needs  of  it's  key  decision  makers.  The  primary  factors  which 
have  contributed  to  this  failure  are  listed  below: 

•  The  AQCESS,  MEPRS,  and  COSTARS  systems  are  independent  and 
incompatible  with  each  other.  Data  sharing  is  impractical  and  duplication  of 
data  collection  and  data  reporting  are  wasteful  of  time  and  resources. 

•  All  of  the  sections  within  the  department  do  not  use  the  same  system.  For 
instance,  the  Family  Practice  Clinic  uses  COSTARS  for  appointments  and 
patient  records  while  the  Consolidated  Troop  Medical  Clinic,  the  Family 
Practice  Clinic  at  the  Consolidated  Troop  Medical  Center,  and  the  General 
Outpatient  Clinic  use  AQCESS  for  appointments  and  patient  information.  The 
Fort  Hunter  Liggett  and  Presidio  of  Monterey  Clinics,  the  Emergency  Medical 
Services,  and  the  Flight  Surgeon's  Office  are  completely  manual. 
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•  Much  of  the  data  kept  by  the  accounting  and  logistical  information  systems 
is  not  divided  by  departments  or  sections,  making  information  extraction 
difficult  and  time  consuming. 

•  The  method  of  inputs  to  the  various  systems  are  different,  making  it 
impossible  to  create  standards  for  data  collection  and  reporting. 

•  Hospital  personnel  are  not  adequately  educated  on  the  capabilities  of  the 
current  information  systems.  In  discussions  with  various  department  and 
hospital  personnel,  it  was  apparent  they  were  unaware  of  the  information 
available  to  them  or  of  the  procedures  required  to  obtain  the  information. 

•  The  reports  produced  by  these  systems  are  in  tabular  format  and  reflect  the 
data  for  one  period  of  time.  Trend  analysis  over  time  is  impossible  without 
further  manual  manipulation  of  the  data.  Summary  information  is  also  difficult 
to  obtain. 

Although  most  of  these  problems  are  unsolvable  within  the  scope  of  this  thesis, 

evaluating  the  difficulties  they  create  within  the  department's  information  system  will 

assist  us  in  identifying  specific  requirements  for  an  improved  information  system. 

D.      PROPOSED  INFORMATION  SYSTEMS 

The  first  two  sections  of  this  chapter  addressed  the  overall  problems  which  exist 
in  the  current  information  system.  In  identifying  what  the  system  lacks,  we  have  thus 
helped  identify  what  an  improved  system  will  require: 

Consistent  data  collection  methods. 

Consolidated  information. 

Concise,  summary  reports  which  are  easy  to  read. 

Analysis  of  department  and  section  performance  trends  over  time. 

Easy  data  input  methods. 

Feedback  for  department  and  section  leaders. 
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•  Standard  reports. 

•  Complete  and  up  to  date  information. 

The  remainder  of  this  chapter  is  an  analysis  of  the  requirements  for  each  of  the 
specific  areas  described  in  Chapter  HI.  Each  section  below  summarizes  the  solutions 
we  propose,  supported  by  the  Department  Chief's  requests,  for  the  six  major  areas 
under  consideration. 

1.      Budget  Information  System 
a.      System  Deficiencies 

The  Department  Chief  has  a  budgetary  system  that  meets  only  his 
minimal  needs.  The  information  listed  below  is  provided  to  the  Department  Chief  in 
tabular  format  by  the  microcomputer  based  spreadsheet  program. 

•  Account  Processing  Code  (APC).  This  code  is  generated  by  the  Resource 
Management  Division  to  identify  separate  identified  fund  accounts.  A  single 
section  can  have  several  fund  accounts. 

Section  name.  The  name  the  department  assigns  to  each  APC  listed  above. 

Allocated  funds  for  the  Quarter.  The  funds  allocated  for  each  APC  for  the 
quarter. 

Supply  Expenditures  for  the  Month. 

Total  Department  Expenditures  for  the  Month. 

Total  Spent  this  Quarter  (cumulative) 

Uncommitted  Funds  this  Quarter. 

Funds  per  Month  (target  expenditure  for  the  section). 

Percent  Spent  for  Month. 

Percent  Saved  for  Month.  This  percentage  is  calculated  by  subtracting  the 
percent  spent  for  the  month  from  100  percent. 
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•  Percent  Spent  for  Quarter. 

•  Percent  Saved  for  Quarter.  This  percentage  is  calculated  by  subtracting  the 
percent  spent  for  the  quarter  from  100  percent. 

This  information,  though  adequate,  does  not  provide  him  with  an  easily  decipherable 

format  nor  the  capability  to  track  spending  habits  for  more  than  one  month.  The  data 

used  to  generate  the  report,  the  Month  End  Report,  is  accurate  but  does  not  necessarily 

reflect  any  recent  section  expenditures.  In  spite  of  this  problem,  the  information  from 

the  Month  End  Report  is  still  considered  accurate  enough  to  be  a  good  indicator  of 

expenditures  for  the  Department  Chief. 

The  Department  Chief  also  receives  budget  information  from  the  two 
intradepartmental  reports,  the  Resource  Information  Report  (RIR)  and  the  Budget  and 
Equipment  Analysis  Report  (BEAR).  The  budget  sections  of  these  reports  are  meant 
to  provide  the  Department  Chief  with  up  to  date  budget  information  that  is  not 
currently  reflected  on  the  monthly  budget  worksheet.  Though  these  reports  were 
designed  to  report  more  current  budget  information,  the  information  actually  reported 
on  the  RIR  and  BEAR  reports  is  a  duplicate  of  the  budget  information  already 
provided  on  the  budget  worksheet.  In  fact,  the  Department  NCOIC  stated  that  he  often 
recopies  the  budget  data  onto  the  reports  from  the  Month  End  Report. 

The  Department  NCOIC  currently  maintains  old  copies  of  each  budget 
report  on  computer  disks.  As  each  new  report  is  needed,  the  Department  NCOIC 
gathers  the  current  information  necessary  to  complete  the  spreadsheet  He  gathers  this 
data  from  either  the  current  Month  End  Report  or  in  the  case  of  a  quarterly  or  yearly 
recap  report,  from  previous  monthly  reports.  Once  this  new  spreadsheet  is  created  for 
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the  report,  he  enters  the  sections'  expenditures  for  the  period  into  the  spreadsheet.  The 
input  of  each  section's  expenditure  requires  the  Department  NCOIC  to  search  through 
the  spreadsheet  and  find  the  location  where  the  information  must  be  entered.  Although 
this  process  is  not  necessarily  difficult,  it  is  cumbersome  and  requires  the  Department 
NCOIC  to  have  a  working  knowledge  of  both  the  spreadsheet's  format  and  the 
application  program.  This  system  can  be  handled  by  a  highly  computer  literate 
individual  like  the  current  Department  NCOIC,  but  could  easily  become  unworkable 
under  a  different  NCOIC. 

Data  analysis  requiring  more  than  one  month's  data  would  involve  the 
combination  of  several  separately  maintained  spreadsheets.    The  old  data  is  replaced 
each  time  a  new  report  is  created.    The  elimination  of  historical  data  makes  long  term 
trend  analysis  extremely  difficult  and  cumbersome. 
b.      Proposed  System  Improvements 

Data  entry  can  be  made  simpler  by  standardizing  the  screen  displays 
and  inputs  and  by  making  the  program  environment  transparent  to  the  user.  This  data 
can  also  be  maintained  in  a  more  accessible  format,  such  as  a  database,  for  ad  hoc 
inquiries.  Maintaining  the  data  within  one  consolidated  database  will  also  provide  the 
capability  to  do  long  term  analysis  of  expenditures.  This  ability  to  access  the  data 
allows  the  sections  to  retrieve  information  on  their  performance  in  the  same  format  as 
seen  by  the  Department  Chief. 

The  data  output  can  be  improved  through  the  use  of  graphs.  The 
graphs  will  be  used  to  display  budgetary  trends  on  a  yearly  basis  which  provides  the 
Department  Chief  with  a  clearer  picture  of  the  budget  fluctuations  and  trends  over 
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time.  These  graphical  printouts  allow  better  analysis  of  the  budget  information  with  a 

lot  less  mental  manipulation  of  the  data.  Printed  tabular  reports  can  be  improved  by 

reorganizing  the  presentation  of  the  information. 

c.      Impact  of  Automation 

Dr.  Ertel  best  characterized  the  role  of  the  microcomputer  in  automation 

by  his  statement: 

The  proper  role  for  the  computer  is  to  do  what  it  does  best:  scan  large  numbers 
of  records... rapidly,  apply  its  infallible  memory  for  detail,  and  serve  as  a 
communications  link.  (Ertel,  1984,  p.  485) 

The  primary  goal  in  our  requirements  specification  is  to  avoid  the  creation  of  any 

additional  and  senseless  work.  This  means  avoiding  the  automation  of  something  that 

does  not  need  automating  while  automating  those  things  that  best  fit  the  advantages  of 

the  microcomputer. 

The  budget  system  is  already  automated,  though  only  in  a  limited  sense. 

The  improvements  described  in  the  previous  section  will  have  the  following  impact  on 

the  current  information  system: 

Simplification  of  the  input  process. 

The  capability  to  maintain  a  larger  database  to  facilitate  trend  analysis  and 
graphing. 

Enhance  the  information's  worth  to  the  decision  maker. 

The  capability  to  graph  the  data  versus  displaying  it  in  its  current  tabular 
format. 

Reduce  the  amount  of  time  the  person  who  receives  the  information  must 
spend  in  deciphering  the  data  to  turn  it  into  useful  information. 

Provide  for  a  user  friendly  system  that  will  not  require  the  user  to  master  a 
computer  or  to  learn  a  particular  applications  program. 
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•  Providing  the  user  with  a  menu  driven  work  environment  should  make  the 
transition  between  users  less  complicated. 

•  Enhance  the  choice  of  outputs  (the  ways  the  data  can  be  viewed)  for  the 
Department  Chief  and  his  sections. 

d.      Impact  of  Proposed  System 

The  information  provided  by  the  new  budget  information  system  will 
provide  the  decision  maker  with  a  more  succinct  view  of  the  budget  information  than 
he  currently  receives.  As  discussed  in  the  introductory  sections,  the  Department  Chief's 
time  is  limited  and  the  ability  to  see  the  impact  of  information  quickly  without  any 
major  data  manipulations  is  critical.  The  addition  of  a  trend  analysis  capability  will 
provide  the  Department  Chief  with  the  ability  to  forecast  and  manage  his  future  budget 
requirements.  By  being  able  to  pictorially  depict  his  budget  trends  and  status,  the 
Chief  can  keep  himself,  his  subordinates,  and  his  superiors  better  informed. 
2.  Equipment  Procurement  System 
a.      System  Deficiencies 

The  current  equipment  needs  are  identified  through  three  sources:  the 
Resource  Information  Report  (RIR),  the  Budget  and  Equipment  Analysis  Report 
(BEAR),  and  the  Information  Capability  Request  (CAPR).  The  equipment  needs 
identified  by  each  of  the  department's  sections  are  provided  by  the  equipment  sections 
of  the  RIR  and  BEAR  reports.  The  Department  Chief  identifies  new  automated 
equipment  requirements  through  the  Information  Capability  Requests  (CAPR). 

The  RIR  contains  the  following  equipment  information: 

•  Old  Equipment  Status. 

•  New  Equipment  Status. 
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•  Medical  Care  Support  Equipment  (MEDCASE)  items  (equipment  needed). 

•  Capital  Expense  Equipment  Program  (CEEP)  items  (equipment  needed). 

The  BEAR  contains  the  following  equipment  information: 

•  Equipment  to  be  replaced  (immediately,  within  one  year,  within  two  years,  and 
within  three  years). 

•  Money  needed  for  equipment  replacement  (immediately,  within  one  year, 
within  two  years,  and  within  three  years). 

•  Actual  approved  items  now  on  the  CEEP  and  MEDCASE  program  with  the 
date  item  ordered  and  its  projected  arrival  date. 

•  Paper   work    in   progress    for   placing    equipment    either   on    the    CEEP    or 
MEDCASE  programs  and  its  paperwork  status. 

The   problem   with   the    information   provided    in   the    RIR    and    BEAR   reports    is 

redundancy.      Each   report   seeks   to   collect   information   on   only   the   high   priority 

MEDCASE  and  CEEP  requirements  but  within  two  different  timeframes,  quarterly  for 

the  BEAR  and  monthly  for  the  RIR.  These  reports  provide  the  Department  Chief  with 

only  a  limited  look  at  his  equipment  needs  and  tend  to  track  only  those  needs  that  are 

the  most  urgent  (usually  only  MEDCASE  and  CEEP  items).    The  reports  do  not  give 

the  Department  Chief  a  consolidated  look  at  all  of  his  department's  requirements.   This 

fragmented   approach  to   capturing   the   data   makes   it   an    intricate   process   for  the 

Department  Chief  to  estimate  his  future  equipment  needs.  Since  funds  are  limited,  the 

Department  Chief  stated  that  he  needs  a  consolidated  listing  of  all  his  requirements  to 

set    replacement    priorities    throughout    the    department.    The    consolidation    of   this 

information  would  also  be  beneficial  when  bargaining  with  the  hospital's  equipment 

acquisition  board  (Programmed  Budget  Advisory  Committee). 
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The  CAPR  requests  provide  the  Department  Chief  with  the  following 
information: 

•  Functional     area     supported,     i.e.,     automation,     communications,     records 
management,  printing/publishing,  and  visual  information. 

•  Justification  for  the  equipment. 

•  A  description  of  the  changes  and  the  reasons  for  the  change  to  the  existing 
service  (if  applicable). 

•  Source  of  funding  for  the  equipment. 

These  requests  are  only  tracked  as  they  are  generated. 

The  process  of  consolidating  the  equipment  requirements  identified  in 
the  BEAR,  RIR,  and  CAPR  requests  is  tedious  and  requires  the  Department  Chief  to 
manually  consolidate  all  the  section's  separate  reports.  The  current  system  also  does 
not  allow  him  to  track  the  long  term  equipment  requirements  needed  to  determine  if 
there  are  department-wide  problems  in  the  acquisition  of  equipment. 

Other  equipment  needs  that  may  not  be  as  critical  are  not  tracked  or 
monitored.  In  addition,  the  Department  Chief  cannot  track  the  section's  past  reported 
requirements  which  are  either  inadvertently  or  deliberately  not  listed  on  the  current 
report.  This  requires  him  to  either  remember  all  of  the  past  requests  or  manually 
search  through  the  old  RIR  and  BEAR  reports  to  obtain  this  information. 

The  status  of  high  priority  equipment  requests  are  reported  on  the 
BEAR  and  RIR  reports.  The  only  way  to  see  the  status  for  this  equipment  is  to  review 
each  section's  RIR  and  BEAR  reports  for  this  information.  The  Department  Chief 
simply  does  not  have  the  time  to  do  this. 
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b.      Proposed  System  Improvements 

Any  solution  proposed  for  the  equipment  information  system  will 
undoubtably  create  some  additional  work  for  the  department.  Therefore,  the  primary 
consideration  for  the  new  equipment  information  system  will  be  ease  of  data  entry  and 
familiarity  with  the  entry  format.  The  greatest  improvement  to  the  current  system  can 
be  accomplished  by  the  creation  of  a  consolidated  database  where  all  equipment 
requests  can  be  recorded  and  easily  tracked.  To  identify  equipment  requirements,  the 
Department  NCOIC  suggested  the  following  types  of  information  be  used  in  the 
database: 

Item  description. 

National  Stock  Number. 

Section  requesting  the  equipment. 

Date  requested. 

Type  of  request  (MEDCASE,  CEEP,  CAPR,  Other). 

Priority  of  equipment  within  a  category. 

Urgency  of  need  (immediate,  one  year,  etc.). 

Quantity  desired. 

Unit  price  and  associated  extended  price. 

Status  of  request  (requisition  number). 

Cumulative  recap  of  required  expenditures. 
Once  an  item  is  deleted  from  the  active  database  due  to  the  delivery  of  the  equipment, 
its  data  should  be  relegated  to  a  historical  database  for  the  analysis  of  long  term 
equipment  trends. 
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The  design  of  the  user  interface  is  critical.  Once  again,  data  entry 
should  be  simple  and  straightforward.  The  outputs  can  reflect  either  a  recap  by 
equipment  category  or  a  consolidated  listing  of  all  equipment  requirements.  The  current 
reports  should  be  consolidated  into  a  single  report  and  standardized  and  simplified  to 
match  the  inputs  required  by  the  user  data  entry  interface.  The  system  should  be  built 
to  facilitate  ad  hoc  inquiries  on  the  database  and  to  do  limited  mathematical 
calculations  to  subtotal  categories  and  run  cumulative  totals  within  categories. 
c.      Impact  of  Automation 

The  equipment  procurement  information  system  is  not  currently 
automated.  The  most  far  reaching  impact  of  automating  this  system  will  be  the  work 
required  to  enter  data  from  the  consolidated  Resource  Information  Report  into  the  new 
equipment  database.  On  the  other  hand,  the  Department  Chief  considers  the 
availability  of  this  information  important  for  resource  management.  As  stated  earlier, 
a  well  designed  user  interface  should  limit  data  entry  to  the  format  recognized  in  the 
RIR.    Specifically,  automation  will: 

•  Provide  the  department  with  a  consolidated  listing  of  all  equipment 
requirements  and  the  capability  to  report  separate  categories  without  leaving 
the  database. 

•  Provide  the  Department  Chief  with  the  ability  to  request  the  information  in  the 
format  he  needs  for  a  particular  situation. 

•  Provide  a  historical  database  of  equipment  requirements  that  can  be  analyzed 
to  determine  equipment  procurement  trends  over  the  long  term. 

The  Department  Chief  currently  feels  that  the  benefits  associated  with  automation  in 

this  area  will  far  exceed  the  costs,  provided  the  user  interface  is  kept  simple. 
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d.      Impact  of  Proposed  System 

The  proposed  system  will  provide  the  Department  Chief  with  a 
consolidated  listing  of  all  his  sections'  equipment  requirements.  This  information  will 
provide  him  with  a  capability  to  sort  equipment  needs  by  cost,  category,  or  priority 
within  the  separate  equipment  categories,  e.g.,  CEEP,  MEDCASE,  etc.  In  this 
information  lies  the  ability  to  bargain  with  the  hospital  resourcing  committees  by 
having  the  information  readily  at  hand  and  in  a  format  which  will  facilitate  this  "give 
and  take"  environment.  By  knowing  all  of  his  requirements,  the  Chief  can  better 
manage  his  resources  to  meet  those  equipment  needs  that  are  the  most  critical  to  his 
department's  success.  With  his  limited  time,  the  consolidated  format  allows  him  to 
digest  the  information  quickly.  Through  the  listings  of  future  needs,  he  can  better  plan 
the  budgets  to  meet  those  needs.  This  new  system  will  serve  to  facilitate  unique 
information  needs  quickly  and  with  less  inconvenience  in  obtaining  that  data. 
3.      Personnel  System 

a.      System  Deficiencies 

As  discussed  in  the  previous  chapter,  the  Department  Chief  has  two 
areas  of  concern  with  the  personnel  information  system:  tracking  and  reporting 
manpower  levels  and  funding  for  the  Continuing  Medical  Education  (CME)  program. 

The  Department  Chief  currently  tracks  personnel  manning  levels  by 
maintaining  this  information  within  a  word  processing  shell.  This  format  is  not  easy 
to  update.  It  limits  the  types  of  reports  you  can  generate  and  the  type  of  analysis  that 
can  be  done  on  the  data.  Without  an  ad  hoc  capability,  the  Department  Chief  must 
visualize  position  vacancies  by  scanning  the  complete  listing.  This  format  also  restricts 
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the  types  of  additional  data  that  can  be  maintained  with  the  personnel  listing,  i.e., 
doctor  patient  panels,  productivity  information,  or  leave  and  absence  requests.  This 
also  precludes  any  data  interfaces  with  other  information  systems,  such  as  scheduling. 
The  update  process  is  complicated  in  that  it  involves  printing  the  entire  form  and  then 
cutting  the  report  into  individual  sections.  Likewise  a  section  which  requests  a  listing 
must  be  satisfied  with  a  department-wide  listing. 

The  CME  listing  is  currently  maintained  on  a  spreadsheet.  This  type 
of  format,  though  adequate,  hampers  the  ability  of  anyone  to  do  ad  hoc  analysis.  Any 
trend   analysis   beyond  the   current   year   is   limited.   A  person   unfamiliar  with   the 
application  program  may  have  difficulty  updating  the  CME  spreadsheet. 
b.      Proposed  System  Improvements 

The  current  personnel  listing  can  be  integrated  into  a  database  to 
provide  the  Department  Chief  with  the  capability  to  keep  critical  personnel  information. 
The  database  should  contain  the  following  database  files: 

•  Position  Information  (TDA  position,  authorization,  etc.). 

•  Personnel  Information  (Name,  SSN,  and  Known  Loss  Date). 

•  Personal  Information  (Protected,  including  address,  spouses  name,  children, 
birthday,  telephone  number,  etc.). 

•  Leave/Absence  Log  (Interfaces  with  CME  listing  and  scheduling  system,  but 
would  also  include  other  types  of  absences,  i.e.,  leaves,  emergency  leaves, 
other  TDY,  or  unusual  planned  absences). 

•  CME  listing.  (Interface  with  the  Doctor  listing  and  the  Absence  Log  but  also 
includes  critical  CME  information,  i.e.,  estimated  costs,  actual  costs, 
qualification,  etc.). 
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The  various  relationships  between  the  database  files  can  be  kept  transparent  to  the  user. 
All  requested  reports  can  be  created  by  linking  the  needed  database  files.  The 
Department  Chief  will  have  access  to  a  list  of  planned  absences,  anticipated  losses,  and 
vacancies  that  he  did  not  hav^  previously.  The  consolidation  of  the  CME  listing  with 
the  personnel  listing  will  consolidate  the  data  entry  requirements  under  one  person, 
therefore  freeing  critical  personnel  to  do  their  primary  jobs.  This  type  of  data  format 
facilitates  any  type  of  report  the  sections  or  the  Department  Chief  could  request.  In 
addition,  the  scheduler  can  receive  a  list  of  the  planned  absences  and  not  have  to  rely 
on  verbal  notifications  from  the  doctors  (see  Section  D.4.,  Scheduling). 

Once  again,  by  building  a  user  interface  that  is  independent  of  the 
program  used,  the  requirement  for  any  application  programming  familiarity  is  no  longer 
necessary. 

The  current  system  requires  two  separate  routes  for  leave  requests, 
depending  on  the  person  requesting  leave.  The  flow  of  information  can  be  improved 
by  centralizing  all  the  data  entry  and  flows  for  leaves  into  one  location.  By 
centralizing  this  data  flow,  the  leave  requests,  as  well  as  personnel  updates,  can  be 
combined  to  avoid  the  redundancy  of  the  data  maintained. 
c.      Impact  of  Automation 

Automation  will  improve  the  system  in  the  following  areas: 

•  Improved  user  interface.  The  system  can  be  independent  of  the  knowledge  of 
the  user. 

•  The  choice  and  diversity  of  reporting  capabilities  will  be  enhanced. 

•  The  leave  log  is  currently  maintained  manually.  By  automating  this  log,  the 
data  can  be  linked  to  the  other  systems,  particularly  the  scheduling  system. 
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•  The  data  will  be  made  easier  to  maintain  and  to  update. 

•  The  Department  Chief  will  be  able  to  maintain  a  protected  personal  database 
on  his  personnel. 

•  The  need  to  consolidate  all  data  flows  through  one  central  location  will  involve 
changing  some  internal  procedures  within  the  department.  These  changes  must 
be  validated  to  meet  regulations  and  will  cause  some  personnel  changes. 

•  The  initial  setup  will  be  costly  in  terms  of  the  database.  The  maintenance  of 
this  large  database  will  require  the  use  of  a  data  entry  clerk,  but  the  work  can 
be  minimized  by  a  well  designed  user  interface. 

d.      Impact  of  Proposed  System 

With  an  enhanced  database,  the  Department  Chief  can  maintain  the  type 
of  data  he  needs  to  track  his  personnel.  Through  a  vacancy  listing  and  the  anticipated 
loss  listing,  the  Department  Chief  can  always  know,  with  one  simple  listing,  the 
vacancies  or  projected  losses  that  exist  in  his  department.  This  information  can  then  be 
used  at  critical  hospital  meetings  to  quickly  identify  his  needs  in  a  straightforward 
format.  At  the  same  time,  the  addition  of  personal  information,  readily  accessible  to 
him,  makes  his  job  as  senior  counselor  easier.  The  absence  listing  gives  him  a  monthly 
listing  of  the  personnel  that  will  not  be  available  during  a  specified  time  period.  This 
information  is  critical  for  monitoring  the  workload  throughout  the  department  and 
greatly  enhances  the  Department  Chiefs  ability  to  predict  periods  of  high  stress  due 
to  personnel  shortages.  The  management  of  CME  funds  will  always  remain  critical. 
Doctors  need  the  necessary  education  to  keep  them  up  to  date  in  their  medical  practice 
but  in  periods  of  increasing  resource  constraints,  the  ability  to  predict  and  justify'  these 
requirements  is  critical. 
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4.      Scheduling  System 

a.  System  Deficiencies 

Scheduling  is  a  complex,  subjective  process  requiring  a  great  deal  of 
independent  information.  In  the  existing  scheduling  system,  this  information  is 
collected  in  many  different  ways,  at  different  times,  and  in  different  formats.  This 
information  is  subjectively  interpreted  and  evaluated  to  produce  the  three  required 
Family  Practice  schedules  and  the  CTMC/FP  schedules.  Specific  problem  areas  within 
the  current  scheduling  process  (as  shown  in  Chapter  HI,  Figures  15  and  16)  are  listed 
below: 

•  Doctor's  leave  and  TDY  requests  are  verbal.  The  scheduler  depends  on  the 
individual  doctor  to  inform  him  of  upcoming  absences.  There  is  no  standard 
form  or  time  requirements  for  providing  this  information. 

•  The  independent  sources  of  information  are  maintained  informally,  i.e.,  some 
are  recorded  on  yellow  legal  paper,  other  information  is  kept  on  3"  x  5"  cards, 
and  still  others  are  typed  on  regular  white  paper. 

•  There  is  no  formal  instruction  for  the  collection  or  maintenance  of  the 
information  necessary  for  scheduling.  The  Assistant  Department  Chief  (ADC) 
currently  keeps  all  the  scheduling  paperwork  in  a  manila  folder  and  the 
CTMC/FP  chief  has  a  green  log  book  in  which  he  records  doctor  availability 
information. 

b.  Proposed  System  Improvements 

The  subjective  nature  of  the  scheduling  process  and  the  diverse  sources 
of  the  necessary  information  place  restrictions  on  the  improvements  which  can  be  made 
and  the  resulting  benefits  of  these  improvements.  We  feel  attempting  to  automate  the 
process,  in  this  case,  is  infeasible.  Automated  scheduling  applications  requires  integer 
programming  and  optimization  techniques  far  beyond  the  scope  of  this  thesis. 
Additionally,  complex  scheduling  algorithms  often  require  the  computing  power  of  a 
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mainframe  computer  for  the  rapid  calculations  and  reiterations  of  scheduling  models. 
(Lyons,  1983,  p.  438)  Therefore,  instead  of  concentrating  on  the  process  of  actually 
creating  the  schedule,  we  propose  improved  methods  of  collecting,  maintaining,  and 
assimilating  the  necessary  information.  Developing  a  scheduling  optimization  model 
could  be  the  subject  of  future  research. 

As  described  in  the  previous  section  on  the  Personnel  System,  an 
automated  leave/TDY  log  could  be  used  to  record  all  requests  for  leave  as  soon  as 
they  are  approved  by  the  Department  Chief.  A  simple  report  listing  each  doctor's 
requested  leave  dates  could  be  produced  for  the  ADC  just  prior  to  the  creation  of  the 
following  month's  schedule.  This  would  ensure  the  ADC  had  all  doctor's  leave  and 
TDY  dates,  without  having  to  rely  on  verbal  information  or  "Post-it-Notes"  stuck  on 
his  office  door. 

In  evaluating  the  other  methods  for  collecting  and  maintaining  doctor 
information,  we  found  that  automation  would  again  be  infeasible.  In  this  case,  the 
department  schedulers  do  not  have  ready  access  to  microcomputers  and  will  probably 
not  have  access  in  the  near  future.  Additionally,  automating  manual  records  can 
sometimes  cause  more  work  than  it  saves.  For  instance,  in  keeping  the  monthly 
cumulative  tally  sheet  described  in  Chapter  III,  the  ADC  simply  puts  tick  marks  beside 
doctors  names  to  show  how  many  times  they  were  on  call  for  the  month.  If  this  tally 
sheet  were  automated,  what  now  takes  the  ADC  2  or  3  minutes  to  perform  might  take 
10  or  15  minutes  by  the  time  he  turns  the  computer  on,  loads  the  application  program, 
and  selects  and  updates  the  doctor's  information. 
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Improvements  can  be  made,  however,  if  the  forms  for  recording  and 
reporting  information  are  standardized  and  a  more  formal  method  of  coordinating  the 
information  is  developed.  Using  the  monthly  cumulative  tally  sheet  to  illustrate, 
preprinted  forms  with  the  months  of  the  year  listed  across  the  top  and  the  doctors 
names  on  the  left  could  be  used  instead  of  the  handwritten  yellow  legal  paper.  Other 
forms  depicted  in  Chapter  III,  Figures  15  and  16  could  be  standardized  and  preprinted. 
This  would  make  formalizing  instructions  easier  and  would  positively  influence  the 
scheduler's  assimilation  of  data  when  producing  the  schedules. 

Keeping  these  standardized  forms  in  a  folder  or  binder  is  sufficient,  as 
long  as  there  are  some  basic  instructions  on  where  to  get  the  printed  forms  (e.g.,  the 
department  secretary's  office)  and  the  doctor's  leave  report  so  that  a  newcomer  to  the 
job  will  not  revert  to  an  unorganized  system. 

c.  Impact  of  Automation 

As  presented  in  the  last  two  sections,  automating  the  scheduling  process 
for  the  DFPCM  would  be  infeasible  within  the  scope  of  this  thesis.  Where  automation 
would  benefit  the  scheduling  process  is  in  providing  consolidated  information 
concerning  doctor's  leave  and  TDY  requests.  This  is  discussed  more  fully  in  the 
section  on  personnel.  The  preprinted  forms  for  standardizing  the  information  collection 
and  maintenance  functions  could  be  created  and  kept  on  a  floppy  disk  in  the 
department's  administrative  office.    They  can  then  be  printed  as  needed  by  the  ADC. 

d.  Impact  of  Proposed  System 

The  improvements  suggested  for  the  scheduling  system  deal  mainly 
with  organization  and  standardization  of  the  information  collection,  maintenance,  and 
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reporting  functions.  Although  the  process  will  remain  virtually  the  same,  the 
schedulers  will  find  it  much  easier  to  gather  and  assimilate  the  data  concerning  the 
individual  doctor's  availability  status.  Designing  a  good  manual  user  interface  (forms, 
reports,  instructions,  etc.),  like  designing  a  computer  user  interface  (menus,  data  entry 
forms,  reports,  screens)  is  important.  "You  will  learn  and  use  a  system  better  if  it  has 
a  consistent  user  interface."  (Burnett,  1988,  p.  29)  Organizing  and  standardizing  the 
various  forms  and  reports  will  assist  the  scheduler  in  recording,  finding,  and 
understanding  necessary  information.  It  will  also  be  much  easier  for  him  to  explain 
the  system  when  he  turns  the  scheduling  job  over  to  another  person,  as  often  happens 
in  the  military.    Clear  instructions  are  vital  for  a  good  transition  file. 

The  process  of  scheduling  department  doctors  will,  for  the  time  being, 
remain  a  subjective  decision  making  process.     Formalized  methods  of  collecting  and 
reporting  information,  however,  will  ease  the  process  by  allowing  the  department 
schedulers  to  more  rapidly  assess  the  information  presented  to  them. 
5.      Patient  Satisfaction  System 
a.      System  Deficiencies 

Patient  satisfaction  is  difficult  to  define  and  measure.  The  concept  of 
satisfaction  is  viewed  differently  by  each  patient  and  is  influenced  by  different  factors. 
One  person  may  base  satisfaction  on  the  courtesy  of  the  doctor,  another  on  the  amount 
of  time  he  had  to  wait  to  see  the  doctor.  Some  people  agree  that  hospital  satisfaction 
is  "the  consumer's  overall  emotional  feelings  about  a  hospital  following  his  or  her 
visit"  (Swan,  and  others,  1987).  Because  of  the  differences  in  opinions  on  this  matter, 
it   is   important   to   identify   some   basic   dimensions   which   might   be    indicators   of 
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satisfaction.  The  evaluation  of  these  dimensions  can  then  be  determined  by  using  a 
questionnaire  to  measure  patient  opinion  on  the  various  dimensions.  It  is  also 
important  to  realize  that  "many  questionnaires  are  developed  not  with  the  intent  of 
determining  global  patient  satisfaction,  but  instead,  to  address  only  those  dimensions 
of  satisfaction  with  which  an  organization  is  willing  or  able  to  react".  (Pelletier,  1985) 

Applying  these  concepts  to  the  DFPCM  involved  evaluating  the 
effectiveness  of  the  current  patient  satisfaction  questionnaire  and  the  value  of  the 
information  it  provides. 

The  basic  content  of  the  current  questionnaire  closely  matches  the 
Department  Chief's  desires.  Table  IV  shows  the  dimensions  of  satisfaction  perceived 
by  the  Department  Chief  as  necessary  for  effective  evaluation  of  patient  satisfaction. 
The  current  questionnaire  covers  most  of  these  dimensions  except  as  noted  in  Table  IV. 
The  questionnaire  lacks  two  important  features:  a  brief  explanation  of  the  purpose  of 
the  questionnaire;  and  instructions  for  completing  and  submitting  the  questionnaire.  The 
patient  currently  receives  verbal  instructions  from  the  doctor  distributing  the 
questionnaire.    These  instructions  will  vary  slightly  from  doctor  to  doctor. 

The  format  for  obtaining  patient  response  is  not  as  effective  as  it  could 
be.  Instead  of  "YES/NO"  questions,  the  Department  Chief  would  like  the  answers  to 
be  scaled,  e.g.,  options  from  poor  to  excellent  using  a  scale  of  one  to  five.  "YES/NO" 
questions  are  considered  too  restrictive  while  a  scale  indicates  a  degree  of  intensity 
(Duffe,  1985).  For  our  purposes,  a  scale  would  show  the  general  level  of  patient 
satisfaction  with  respect  to  the  given  dimensions. 
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Table  IV  DIMENSIONS  OF  SATISFACTION 

**         ACCESS  TO  CARE  How  long  it  takes  to  get  an  appointment. 

WAITING  TIME  How  long  it  takes  to  see  a  doctor. 

COURTESY  OF  STAFF  Doctors,  Nurses,  Clerks. 

UNDERSTAND  TREATMENT  Explanation  of  procedures. 

CLINICAL  ENVIRONMENT  Cleanliness  of  clinic. 

PHYSICIAN  TIME  Adequacy  of  time  spent  with  doctor. 

ALLOCATION 

GENERAL  SATISFACTION  General  opinion  of  the  care  received  for  a  particular 

visit. 

**  Dimensions  not  included  in  current  questionnaire 

The  primary  problem  with  the  existing  system  is  in  the  output  generated 
from  the  questionnaire  results.  Each  question  is  treated  as  a  discrete  entity,  one 
indicator  of  an  important  aspect  of  care.  As  such,  only  one-time,  discrete  response 
rates  can  be  obtained  for  each  question.  Additionally,  the  questionnaire  results  are  not 
being  tracked  or  reported.  As  discussed  throughout  this  thesis,  the  Department  Chief 
wants  summary  information  which  depicts  comparisons  and  trends.  The  Monitor  and 
Evaluation  reports  do  not  provide  this  information. 
b.      Proposed  System  Improvements 

There  are  two  basic  improvements  which  need  to  be  made  for  the 
patient  satisfaction  system.  First,  the  questionnaire  must  be  redesigned  to  include  all 
of  the  dimensions  of  satisfaction  identified  by  the  Department  Chief,  listed  in  Table  IV. 
This  redesign  must  also  incorporate  the  desired  scales  for  applicable  questions.  In 
addition,  the  questionnaire  should  include  a  statement  of  purpose  and  instructions  to  the 
patient  on  how  to  complete  and  submit  the  questionnaire.    Although  some  literature 
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suggests  that  a  cover  letter  be  included  (Landry,  1987,  p.  16),  we  believe  a  simple  one 
page  questionnaire  will  be  received  better  by  the  patients  and  will  be  easier  to  collect 
and  review. 

Secondly,  the  results  of  the  questionnaire  need  to  be  reported  in  a  more 
meaningful,  effective  method.  The  Department  Chief  should  be  able  to  view  trend 
lines  and  other  graphical  information  to  determine  the  level  of  satisfaction  with  respect 
to  various  dimensions.  Comparing  the  dimensions,  when  appropriate,  should  also  be 
made  easier.  Providing  this  information  using  automation  would  require  the 
questionnaire  data  to  be  entered  into  a  computer  program  which  would  manipulate  and 
compute  the  desired  results  and  produce  the  desired  output. 
c.       Impact  of  Automation 

If  the  responses  in  the  questionnaire  are  coded,  the  patient  response  can 
be  easily  entered  into  a  computer.  Once  this  is  done,  the  application  program  would 
automatically  compute  the  results  and  print  or  display  the  desired  output  in  tabular  or 
graphical  form.  Automation  will  allow  rapid  trend  analysis  and  graph  generation  and 
provide  a  means  for  storing  historical  results  for  future  analysis  if  desired.  To  perform 
these  functions  manually  would  require  an  inordinate  amount  of  time  and  the  resulting 
benefits  would  thus  be  outweighed  by  the  costs.  The  Department  Chief  has  clearly 
stated  the  shortage  of  personnel  in  his  department  precludes  implementing  any  system 
which  would  require  excessive  input  or  evaluation  time.  The  time  the  QA  representative 
now  spends  hand  calculating  the  results  of  the  current  questionnaire  would  be  converted 
to  time  spent  by  a  data  entry  clerk  entering  the  raw  data  from  the  returned 
questionnaires. 
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d.      Impact  of  Proposed  System 

The  proposals  outlined  above  will  improve  the  patient  satisfaction 

information  system  in  several  ways: 

A  questionnaire  which  is  easy  to  understand  and  complete  is  more  likely  to 
be  submitted  by  the  patients. 

Improved  questions  will  meet  the  Department  Chief's  stated  dimensions  of 
satisfaction. 

Redesigned  answer  formats  (scales)  will  provide  more  meaningful  information 
to  the  Department  Chief  on  the  level  of  satisfaction  of  the  patients. 

Automated  applications  will  free  the  QA  representative  from  the  time 
consuming  task  of  hand  calculating  the  response  rates  for  each  question. 

Through  automation,  improvements  in  data  analysis,  storage,  and  reporting  can 
be  realized  with  rninimal  time  requirements. 

Producing  more  meaningful  reports  will  allow  the  Department  Chief  to  spend 
less  time  analyzing  the  data  and  draw  more  accurate  conclusions  from  the 
information  presented.  Trend  analysis  and  historical  comparisons  will  give 
indications  of  possible  problems  and  potential  improvements  in  the  care 
provided  by  the  department. 

6.      Productivity  System 

a.      System  Deficiencies 

The  main  problem  with  the  productivity  information  system  is  that  only 
the  CTMC  and  CTMC/FP  clinics  are  being  monitored  for  productivity.  The 
Department  Chief  likes  most  of  the  tables  and  graphs  produced  by  the  Clinical  Support 
Division  for  the  CTMC  clinics  but  would  like  to  receive  this  information  for  each  of 
his  other  sections.  Unfortunately,  all  of  the  sections  do  not  use  the  same  system  to 
record  patient  visits  and  doctor  workload.  CTMC  uses  AQCESS,  Family  Practice  uses 
COSTARS,  and  other  sections  use  a  manual  system.    Thus,  to  provide  the  Chief  with 
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the  information  he  desires  will  require  collecting  and  consolidating  the  clinic  and 
doctor  workload  statistics  from  each  separate  clinic. 
b.      Proposed  System  Improvements 

The  Department  Chief  is  interested  in  obtaining  productivity  information 
for  two  distinct  purposes:  monitoring  each  individual  doctor's  workload  (based  on  the 
number  of  patients  seen),  and  monitoring  the  overall  workload  of  each  clinic  (based  on 
the  total  number  of  visits). 

Monitoring  each  doctor's  productivity  was  determined  to  be  beyond  the 
scope  of  this  thesis  for  the  following  reasons: 

•  Only  clinics  using  automated  appointment  systems,  i.e.,  AQCESS  and 
COSTARS,  maintain  individual  doctor  workload  data. 

•  Productivity  information  for  each  doctor  would  be  impractical  to  obtain 
manually  because  of  the  high  volume  of  patients  treated  by  each  clinic. 

•  The  appointment  systems  use  different  measures  of  doctor  availability  and  do 
not  factor  in  doctor  absences,  e.g.,  leave  and  TDY,  when  computing  doctor 
workload.  These  disparities  result  in  inconsistencies  between  the  resulting 
doctor  productivity  figures. 

For  these  reasons,  individual  doctor  productivity  will  not  be  discussed  in  the  remainder 

of  the  thesis  but  could  be  the  subject  of  future  research. 

Overall  clinic  workload  data,  in  terms  of  the  number  of  patient  visits, 

is  reported  monthly  by  each  section  to  the  Patient  Administration  Division  (PAD).  This 

information  is  already  mandatory  and  can  be  obtained  from  PAD  either  manually  from 

the  printed  MED  302  report  or  automatically  from  the  data  in  the  PAD  worksheet  (see 

discussion  in  Chapter  HI).    The  use  of  an  automated  data  capture  routine  will  preclude 
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the  sections  from  having  to  provide  another  copy  of  their  workload  reports  to  the 
department. 

The  improvements  necessary  to  obtain  the  clinic  productivity 
information  involve  collecting  all  of  the  section's  visit  data  for  entry  into  an  overall 
department  system.  With  a  consolidated  database  of  department  visit  information, 
productivity  reports  can  be  produced  to  show  monthly  clinic  workload  and  yearly 
productivity  trends.  The  productivity  database  can  be  combined  with  the  budget 
database  to  produce  information  relating  department  and  clinic  monthly  expenditures 
to  monthly  workload  data. 

c.  Impact  of  Automation 

Automating  clinic  workload  reporting  would  result  in  the  following 
benefits: 

•  The  Chief  can  monitor  the  aggregate  workload,  by  section,  to  determine  trends 
in  patient  visits  and  the  need  to  shift  resources  to  meet  needs. 

•  The  department  will  be  able  to  monitor  its  workload  in  relation  to  its  budget. 

d.  Impact  of  Proposed  System 

The  aggregate  number  of  patient  visits  is  important  information.  The 
number  of  patients  seen  by  a  section  can  be  compared  with  the  dollar  amounts  of 
supplies  used  to  track  and  estimate  budget  requirements  and  justify  spending  patterns 
for  the  Department  Chief.  The  trends  and  seasonal  changes  in  patient  visits  can  be 
analyzed  over  time  to  assist  the  Department  Chief  in  planning  for  future  requirements. 
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V.    REQUIREMENTS  ANALYSIS 

A.      INTRODUCTION 

This  chapter  presents  the  requirements  analysis  for  the  DFPCM  information 
system.  These  requirements  were  determined  through  prototyping  as  discussed  in 
Chapter  II.  The  requirements  analysis  is  based  on  the  functional  specifications  for  each 
system  described  in  Chapter  IV  and  provides  a  more  detailed  look  at  the  inputs, 
outputs,  data  structures  and  user  interfaces  required  to  meet  the  functional 
specifications.  We  used  User  Concept  Diagrams  (UCDs),  described  in  the  following 
section,  to  depict  the  requirements  for  the  systems  and  aid  in  establishing  the 
prototypes. 

Having  analyzed  the  current  system  (Chapter  III)  and  proposed  improvements 
(Chapter  IV),  the  requirements  analysis  is  the  first  step  toward  actually  building  an 
improved  information  system.  This  thesis  takes  the  requirements  analysis  phase  of  the 
development  life  cycle  through  one  iteration  of  the  requirements  prototype.  The 
number  of  iterations  which  will  ultimately  be  required  for  the  prototype  is  unknown 
and  will  vary  for  different  development  projects.  Once  the  prototypes  are  accepted  by 
the  users,  the  system  development  can  continue  with  design  and  implementation.  The 
remainder  of  the  chapter  presents  the  identified  requirements  for  the  DFPCM 
information  system. 
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B.       USER  CONCEPT  DIAGRAMS 

Chapter  HI  introduced  data  flow  diagrams  as  a  way  to  depict  the  current 
information  system.  Although  DFD's  are  being  used  extensively  by  systems  analysts, 
there  are  many  other  methods  available  for  relating  information  system  functions  and 
data  flows  to  the  user.  One  of  these  methods  is  the  User  Concept  Diagram  (UCD) 
developed  by  Charles  F.  Martin  in  1988. 

Martin  designed  UCDs  to  supplant  DFDs  for  representing  the  information  system 
to  the  user.  UCDs  have  several  advantages  over  DFDs.  These  advantages  result  from 
the  use  of  additional  symbols  to  represent  entities  and  interactions  not  present  in  DFDs. 
The  major  advantages  are  listed  below: 

•  External    entity    symbols   clearly    indicate   data   flows    into    and   out   of  the 
automated  system. 

•  The  use  of  multiple  symbols  for  external  entities  more  closely  depicts  the 
objects  they  are  intended  to  represent. 

•  The  intended  user  is  identified  with  his  type  of  interface  so  the  interactions 
of  the  system  can  be  designed  for  compatibility  with  intended  users. 

•  Symbols  can  be  easily  drawn  with  standard  flow  chart  templates  or  automated 
graphics  packages. 

•  Different  storage  and  output  mediums  can  be  easily  portrayed.  (Martin,  1988, 
pp.  65-84) 

Figure   21    shows  the   basic   UCD  symbols   (more   can   be   created   to  meet   a 

particular  analyst's  needs).    Although  UCDs  use  more  symbols,  the  resulting  diagrams 

are  easier  to  explain  to  the  users  because  they  are  "pictorially  more  suggestive  of  the 

objects  they  represent"   (Martin,    1988,  p.   65).      We   found  this  to  be  true   in  our 
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interactions  with  the  DFPCM  users.    Thus,  in  the  requirements  analyses  that  follow, 
we  use  UCDs  to  depict  the  department's  information  system  requirements. 


Automated 
function 


Screen  display 


Data  flow 


On-line  date 
store 


Hardcopy  reports 


Diskette  storage  or 
communication  of  data 


Off-line  data 
storage 


nl  Indication  of 

intended  user  and 
type  of  workstation 


JE 


£— * 


External  entities 


Indication  of  major 

user  and  machine 

interaction  with  the 

given  function 


Figure  21.    User  Concept  Diagrams 

C.      GENERAL  REQUIREMENTS 
1.      User  Interface  Design 

The  design  of  the  interface  is  perhaps  one  of  the  most  critical  aspects  in  the 
development  of  a  prototype  for  the  DFPCM.  "Ease  of  use",  "user  friendly",  and 
"ergonomic  design"  are  all  industry  buzzwords  that  simply  mean  one  thing:  make  the 
interface  work  for  the  user  in  the  way  they  expect  it  to  work  in  their  environment. 
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Many  factors  determine  who  will  be  the  users  and  when  and  how  they  will  use  the 
system.  The  environment  at  the  hospital  provides  a  challenging  set  of  circumstances 
for  the  design  of  the  interface.  The  target  DFPCM  information  system  user  will  most 
likely  be  a  novice,  untrained  in  both  computers  and  applications  programs.  He  or  she 
will  not  have  the  time  to  learn  complicated  applications  program  because  of  many 
more  urgent  duties.  The  information  system  will  not  have  dedicated  data  entry  clerks 
and  will,  in  all  probability,  rely  on  the  availability  of  someone  who  has  other  pressing 
matters  at  hand. 

Martin's  Human  Factors/Computer  Knowledge  Structure,  as  depicted  in  Table 
V,  served  as  the  basis  for  the  interface  designs  in  developing  the  initial  prototype 
(Martin,  1987,  p.  335). 

To   properly    humanize    software    through    the    use    of  ergonomic    design 

principles,  Knittle  and  Gardner  suggest  the  designer  follow  the  principles  listed  below 

(Knittle,  1987,  pp.  164-171): 

•  Minimize  worker  effort.  The  user  should  only  perform  essential, 
non-automatable  tasks,  avoiding  repetition  of  work  already  accomplished 
(Knittle,  1987,  p.  164).  All  inputs  should  be  in  the  format  that  the  user  is 
already  familiar  with,  i.e.,  a  commonly  used  written  form  or  report. 

Minimize  worker  memorization. 

Minimize  worker  frustration.  Keep  the  user  aware  of  delays  in  accomplishment 
and  if  necessary  give  them  progress  reports  (Knittle,  1987,  p.  166). 

Maximize  use  of  habit  patterns. 

Notify  users  of  problems  promptly. 

Maximize  worker  control  of  tasks. 

Maximize  task  support. 
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Table  V     HUMAN  FACTORS/COMPUTER  KNOWLEDGE  STRUCTURE  (Martin  and 
Fuerst.  1987,  p.  335) 


Human  factor 

Human  subfactor 

User  computer  knowledge 

Novice 

Experienced 

Nature  of  message 

Tone 

Explanatory  and 
polite 

Short  and  to  the 
point 

Use  of  humor 

Careful 

None 

Bypasses 

None 

Allow 

Warnings 

Many 

Rarely 

Screen  format 

Menu 

Inquiry 

Input  verification 

Always 

Rarely- 

High  lighting 

Some  (judiciously) 

Little 

Defaults 

With  explanation 

Without  explana- 
tion 

Screen  discontin- 
uation 

Prompt  and  keyed 
response 

Keyed  response 
without  prompt 

Help  function 

Procedures 

Full,  unsolicited 

Upon  request 

Values 

Full,  unsolicited 

Upon  request 

Response  time 

Mean 

Minimize  within 
variance 

Minimize 

Variance 

Minimize 

Minimize  within 
mean 

Path  process 

Menu  structure 

Depth 

Breadth 

Overall  screen 
density 

Minimize 

Maximize 

Screen  design  is  another  aspect  of  humanizing  software.  Stahl  recommends  the 
following  guidelines  in  the  design  of  screens  which  support  user  friendliness.  (Stahl, 
1986,  p.  60). 

•  Do  not  crowd  the  screen.  "Good  screens  look  good." 

•  Use  highlighting,  blinking,  and  reverse  video  sparingly.  Overuse  will  lead  to 
operator  fatigue. 
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•  Use  color  sparingly.  Color  is  an  appealing  and  proven  way  to  enhance 
computer  input.  The  following  foreground/background  screen  combinations  are 
listed  in  order  of  legibility,  from  the  most  legible  to  the  least  legible  (Ives, 
1982,  pp.  15-47). 

MOST  LEGIBLE  Black  on  Yellow 

Green  on  White 

Blue  on  White 

White  on  Blue 

Yellow  on  Black 

White  on  Red 

White  on  Orange 

White  on  Black 

Red  on  Yellow 

Green  on  Red 

Red  on  Green 
LEAST  LEGIBLE  Blue  on  Red 

•  Limit  the  amount  of  information  on  each  screen  to  what  is  necessary.  Do  not 
force  the  user  to  remember  things  from  one  screen  to  the  next. 

•  Minimize  key  strokes. 

•  Minimize  cursor  movement. 

•  Show  the  maximum  permissible  length  of  an  input  field  with  underscores, 
highlighting,  or  brackets. 

•  Keep  the  screen  consistent  with  paper  input  forms.  Although  all  information 
from  the  paper  form  may  not  need  to  be  entered  on  the  screen,  the  screen 
should  follow  the  general  flow  of  information  on  the  paper  form.  (Kendall  and 
Kendall,  1988,  p.  484). 

Messages  to  the  user,  an  essential  element  in  user  friendly  screens,  should 
be:  (1)  consistently  positioned,  (2)  short,  meaningful,  common  and  fully  spelled  out, 
(3)  affirmative,  (4)  in  the  active  voice,  and  (5)  in  the  temporal  sequence  of  events. 
(Galitz,  1983,  p.  9). 

Another  aspect  of  interface  design  is  the  design  of  menus.  The  user  should 
be  able  to  identify  which  transactions  are  available  through  a  series  of  logically  related 
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and  relevant  events  common  to  a  menu  screen.  The  menu  screens  for  the  DFPCM 
information  systems  are  depicted  in  the  following  sections  by  the  use  of  Menu 
Hierarchy  Charts. 

2.      Standard  Interface  Designs 

Understanding  the  importance  of  a  good  user  interface,  we  designed  a  set 
of  standard  interfaces  for  getting  user  input  and  for  displaying  output  on  the  screen  for 
each  of  the  systems.  The  following  sections  describe  the  standard  input  and  output 
designs  which  are  applicable  to  all  of  the  systems.  Within  the  detailed  requirements 
for  each  system,  we  present  a  specific  description  of  the  data  required  for  the  inputs 
and  outputs  related  to  that  system.  Appendix  A,  the  Data  Dictionary,  contains  detailed 
information  about  the  data  structure  of  the  system's  databases. 
a.      Input  Screens 

The  majority  of  the  input  screens  were  generated  with  a  commercially 
available  database  screen  generator.  The  screen  generator  displays  the  available  fields 
from  the  database  in  use  and  allows  the  analyst  to  load  and  position  the  desired  fields 
onto  the  screen  to  create  a  functional  input  format.  The  program  which  generates  this 
screen  is  saved  and  called  into  use  whenever  the  user  selects  an  input  option  from  one 
of  the  menu  systems.  Appendix  B  is  the  program  listing  of  all  of  the  format  screens 
for  the  DFPCM  information  system. 

The  screen  generator  allows  the  system  designer  to  easily  load  and 
manipulate  the  necessary  input  fields  to  create  good  user  interfaces.  The  screen 
formats  are  easy  to  change  to  suit  the  user's  requirements,  making  the  generator  an 
invaluable  tool  when  prototyping  the  requirements  analysis.    Examples  of  each  of  the 
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input  screens  designed  are  included  with  the  detailed  requirements  analysis  for  each 
system,  with  a  description  of  the  necessary  input  fields. 

Other  standard  input  screens  are  those  used  to  accept  input  from  the 
user  necessary  for  identifying  further  processing  requirements,  such  as  the  year  and 
month  for  a  desired  report  or  a  person's  identification  number  for  updating  his  or  her 
personal  information.  These  screens  are  created  with  programming  commands  which 
identify  where  the  prompts  and  input  blocks  appear  and  any  other  information  needed 
on  the  screen.  An  example  of  these  interactive  screens  is  shown  in  Figure  22.  Where 
possible,  we  have  designed  these  screens  to  position  prompts,  input  blocks,  and 
instructions  in  the  same  locations  and  with  similar  terminology.  Whenever  the  user  is 
asked  to  input  a  coded  response,  e.g.,  the  Section  Code  shown  in  the  example,  he  or 
she  should  be  allowed  to  view  a  help  screen  showing  the  valid  codes  for  that  particular 
item,  e.g.,  FPC  =  Family  Practice  Clinic. 


Enter  the  Year  for  report:  89 
Enter  the  Month  for  report:  10 


I 


Enter  the  Clinic  section  code  for  report:  FPC 


Figure  22.  Sample  Interactive  Input  Screen 
b.      Review  Screens 

In  many  of  the  system  menus,  there  is  an  option  for  reviewing  database 
information  on  the  screen.  The  review  screens  are  easily  created  with  commercially 
available  database  software  (e.g.,  DBASE  HI+)  by  using  a  programming  command  and 
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specifying  the  fields  desired  for  display.    An  example  of  a  typical  review  screen  used 

in  the  DFPCM  information  system  is  shown  below. 

APC  DESCRIPTION  SECT  CODE  POC  TELEPHONE 

W357  FAM  PRAC  CLINIC  FPC  TURNER  8888888 

W358  CTMC-FPC  CFP  SHAW  7777777 

W360  EMERGENCY  MED  EMS  BLAKE  6666666 

The  field  names  are  printed  across  the  top  of  the  screen,  in  the  order  given  in  the 

program  command.     The  specified  fields  for  each  applicable  record  are  displayed 

beneath  the  corresponding  field  tide.    The  analyst  can  program  the  review  screen  to 

allow  the  user  to  change  certain  data  or  prevent  the  user  from  making  any  changes 

while  reviewing  the  database  information.    Review  screens  used  throughout  the  system 

are  similar  in  format.     The  specific  fields  required  for  display  for  each  review  are 

described   within   the   detailed   requirements   for  the   applicable   system.      As   with 

generated  screen  inputs,   analysts  can  easily  update  review   screens  to  meet  user 

requirements  during  prototyping. 

3.      Requirement  Analysis  Constraints 

The  detailed  analyses  which  follow  describe  the  data  structures,  menus, 

inputs,  outputs,  and  user  interactions  for  each  of  the  systems  under  consideration. 

Many   of  the  tables   and  graphs  produced  by  the   systems  require   extensive  data 

manipulations  and  in  some  cases,  interaction  with  more  than  one  software  package. 

The  design  of  the  detailed  programming  for  these  data  manipulations  and  extractions 

is  beyond  the  scope  of  this  thesis  and  is  therefore  not  included  in  the  detailed  system 

requirements.    The  output  examples  were  generated  using  sample  data  similar  to  that 

which  would  be  extracted  from  the  database.    Where  applicable,  the  program  listings 
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for  each  system  contain  comment  statements  indicating  where  data  manipulations  and 
report  generation  would  have  to  occur  to  produce  the  desired  output.  Within  the 
system  requirements  is  a  detailed  description  of  the  data  elements  necessary  to  create 
the  outputs.  The  actual  method  of  output  generation  will  depend  on  the  software 
packages  used.  For  example,  if  the  database  software  has  graphing  capability,  the 
graphs  can  be  generated  internally  from  the  existing  data.  If  not,  the  data  will  have 
to  be  moved  to  a  separate  graphics  software  package  to  produce  the  desired  graphs. 
These  software  specific  constraints  are  not  included  as  part  of  the  requirements  analysis 
but  would  have  to  be  considered  further  in  the  development  life  cycle,  once  the  design 
and  software  selections  have  taken  place. 

D.      DETAILED  REQUIREMENTS 

1.      Budget  Information  System  (see  Program,  Appendix  C) 

Figure  23,  a  user  concept  diagram,  gives  a  picture  of  the  components  of  the 
new  budget  information  system.  The  user  concept  diagram,  as  discussed  in  the  previous 
section,  allowed  us  to  give  the  Department  Chief  a  general  picture  of  the  new 
requirements  necessary  for  the  budget  information  system. 

a.      Data  Structures 

To  successfully  meet  the  needs  of  the  Department  Chief,  the  data 
structure  for  the  budget  system  was  designed  to  provide  maximum  flexibility  in  data 
retrieval  and  analysis.  Each  database  was  designed  to  represent  a  portion  of  the  budget 
process,  e.g.,  the  receipt  of  the  quarter's  budget  allocations  or  the  receipt  of  the 
section's  expenditures  as  reported  in  the  month  end  report.  Figure  24  represents  how 
each  database  relates  with  the  other  databases  in  the  budget  information  system. 
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Figure  23.    Budget  Information  System  User  Concept  Diagram 

The  structure  of  the  data  fields  facilitates  the  combination  of  databases 
through  the  use  of  relationships  among  the  key  fields  between  the  databases.  The  key 
field  identified  throughout  the  budget  databases  is  the  Account  Processing  Code  (APC) 
which  is  used  within  the  hospital  for  financial  accounting  purposes. 

The  APC  database  contains  the  following  data  fields: 

•  Account  Processing  Code.  Hospital-wide  funding  code. 

•  Section  Description.  This  is  the  specific  department  name  associated  with  a 
particular  APC  code. 

•  Section  Code.  This  field  was  designed  to  represent  the  true  organizational 
structure  of  the  department.  It  allows  the  system  to  interrelate  sections  along 
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organizational  lines  versus  the  artificial  budgetary  lines  necessitated  by  the 
APC  funding  codes.  This  convention  allows  other  subsystems  of  the  DFPCM 
information  system  to  relate  budgetary  information  along  the  same  command 
lines,  such  as  is  necessary  in  the  Productivity  system.  The  codes  used  in  this 
field  include: 

DEP  Department  Headquarters 

FPC  Family  Practice  Clinic,  Main  Hospital 

CFP  Family  Practice  Clinic,  Troop  Clinic 

GOC  General  Outpatient  Clinic 

EMS  Emergency  Medical  Services 

POM  Presidio  of  Monterey  Health  Clinic 

CTM  Consolidated  Troop  Medical  Clinic 

FHL  Fort  Hunter  Liggett  Clinic 

AMB  Ambulance  Section 

FSO  Hight  Surgeon  Office 

•  Point  of  Contact  for  budget  matters  within  the  section. 

•  Telephone  Number.  Self  Explanatory. 

•  Status  Code.  A  system  code,  either  "A"  for  active,  or  "I"  for  inactive.  This 
code  is  needed  to  allow  APCs  which  are  no  longer  in  use  (identified  by  an 
I)  to  continue  to  be  linked  with  budget  data  to  maintain  long  term  historical 
APC  information.  The  APC  code,  once  entered  into  the  system,  is  never 
deleted.  Only  active  APCs  (coded  A)  are  displayed  when  a  user  requests  an 
APC  listing. 

The  APC  Allocation  Database  contains  the  following  fields: 

•  APC  code.  Described  above. 

•  Fiscal  Year  (FY). 

•  Quarter.  The  quarter  of  the  given  fiscal  year. 

•  Allocation:  The  funds  allocation  for  the  APC  in  the  first  field  further 
delineated  by  the  Fiscal  Year  and  Quarter  fields. 

The  APC  Monthly  Expenditure  Database  contains  the  following  fields: 

•  APC  code,  as  described  earlier. 

•  Fiscal  Year  of  expenditure. 
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•  Month  of  expenditure. 

•  Quarter  of  expenditure,  computed  from  the  month  field,  i.e.,  if  month  is  10, 
quarter  is  1. 

•  Expenditure  for  the  month. 
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Figure  24.    Budget  Information  System  Data  Structures 
b.      Data  Inputs 

The  user  will  be  required  to  maintain  the  databases  discussed  above 
through  three  database  interfaces.  The  three  interfaces  are: 

•  Enter  or  delete  quarterly  allocations. 

•  Enter  or  delete  monthly  expenditures  for  each  section. 

•  Enter  or  change  the  status  of  a  section's  APC  information. 

The  menu  hierarchy  chart  is  depicted  in  Figure  25.  As  discussed  in  the 
previous  section  of  this  chapter,  the  user  is  required  to  enter  the  fiscal  year  to  limit  the 
database  search.  If  necessary,  the  month  or  quarter  within  the  selected  fiscal  year  is 
also  entered.  These  entries  are  standardized  as  discussed  in  Section  C,  General 
Requirements.    All  entries  within  a  particular  menu  cycle  are  restricted  to  the  user's 
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chosen  fiscal  year.  This  restriction  is  desired  because  most  data  entries  will  require  the 
same  fiscal  year  since  the  user  usually  works  in  one  fiscal  year  at  a  time.  To  change 
fiscal  year  while  working  in  the  selected  menu,  the  user  must  return  to  the  main  menu 
and  enter  the  new  fiscal  year  when  prompted.  The  entries  within  the  selected  menu 
cycle  are  limited  to  the  chosen  fiscal  year  so  the  user  does  not  have  to  re-enter  the 
fiscal  year  for  each  additional  expendiuire  or  similar  input. 

In  the  cases  where  the  APC  is  entered  by  the  user,  the  system  verifies 
the  code  entered  against  the  active  APC  information  database  and,  if  the  APC  is  found, 
confirms  the  user's  choice  with  the  following  screen. 

Section:  WMMNHMBMMIIM&SE&Mi  Section  Code:  RBS 

Point  of  Contact:  SBBBSSSSBBBSM      Telephone  HBBBRN9RGI 
This  confirmation  prevents  the  entry  of  either  a  wrong  or  inappropriate  APCs  that 
would  destroy  the  integrity  of  the  allocation  and  expenditure  databases.  If  the  APC  is 
not  found,  an  appropriate  warning  is  issued  to  the  user  and  he  or  she  is  allowed  to 
try  again. 

Figure  26  is  a  picture  of  the  user  input  screen  used  for  the  entry  and 
deletion  of  a  quarter's  budget  allocation  for  a  given  APC.  The  fiscal  year,  APC,  and 
quarter  have  already  been  entered  by  the  user  and  will  appear  on  the  input  screen. 
This  screen  is  modified  when  used  in  the  deletion  process  by  the  addition  of  a 
comment,  Delete  this  Record?  (Y/N)  g  ,  at  the  bottom  of  the  screen. 

Figure  27  depicts  the  user  input  screen  that  allows  the  user  to  enter  the 
monthly  expenditures  for  a  particular  APC.  As  discussed  previously,  the  user  can  only 
enter  the  actual  allocation  for  the  month.     The  month  and  APC  have  already  been 
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Figure  25.    Budget  Information  System  Menu  Hierarchy  Chart 
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entered  and  verified  to  be  correct.  This  format,  modified  like  the  quarterly  format,  is 
also  used  for  verification  prior  to  the  deletion  of  a  record. 


Enter  the  Quarterly  Allocations 
for 
Fiscal  Year   89 


Quarter      1 
APC  Code     W140 

Allocation 


Figure  26.    Quarterly  Budget  Allocation  Input  Screen 


Enter  the  Monthly  Expenditure 


APC    Code 

W-156 

Month 

10 

Expenses 

■in  i     mil 

Figure  27.  Monthly  Expenditure  Input  Screen 

Figure  28  depicts  the  user  input  screen  that  allows  the  user  to  enter  or 
change  an  APC.  The  entry  of  a  new  APC  is  preceded  by  verification  that  the  APC 
requested  is  not  in  the  current  database.  If  the  requested  APC  is  found  in  the  existing 
database,  the  user  is  warned  and  allowed  to  try  again.  The  user  is  not  allowed  to 
reenter  the  APC  once  the  screen  in  Figure  28  is  presented.  This  prevents  redundancy 
in  data  entry  and  keeps  the  user  from  circumventing  the  duplicate  APC  check 
procedure.  The  section  codes  are  displayed  on  the  screen  to  facilitate  user  entries. 
Inactivation  of  the  APC  is  allowed  when  the  user  is  prompted  with  "Do  you  wish  to 
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put  (his  APC  into  inactive  status?  (Y/N)  |  ".  If  the  user  wants  to  change  a 
particular  APC's  status  code  to  inactive,  the  APC  record  is  automatically  annotated 
with  the  new  status  code.  Activation  to  an  active  status  is  automatic  when  the  user  first 
enters  a  new  APC. 


APC    Code    Entered    ->    W-140 


SECT I 01 


Section  Code 


Point  of  Contact 


Telephone  Number   (HB 


SECTION 

CODES 

Family  Practice  Clinic 

FFC 

Consolidated  Troop  Clinic 

CTM 

General  Outpatient  Clinic 

GOC 

Fort  Hunter  Liggett  Clinic 

FHL 

CTMC-Family  Practice 

CFF 

Ambulance  Section 

AME 

Emerqency  Medical  Service 

EMS 

Flight  Surgeon  Office 

FSO 

Presidio  cf  Monterey 

POM 

Department 

DEF 

Figure  28.  APC  Information  Input  Screen 
c.       Outputs 

Outputs  are  divided  into  two  general  categories.  Review  screens 
(discussed  in  Section  B  of  this  chapter)  and  pre-formated  reports.  The  three  general 
review  screens  presented  to  the  user  are  depicted  in  the  menu  hierarchy  chart  in  Figure 
25  as  the  menu  options  either  to  review  allocations,  expenditures,  or  all  of  the  APC 
information.  Each  review  option  provides  the  user  with  the  generic  review  display 
as  described  in  Section  B  of  this  chapter.  The  data  fields  presented  in  each  case  are 
the  complete  data  fields  of  the  respective  active  database. 

(1)  Monthly  Budget  Expenditure  Report.  Figure  29  is  an  illustration 
of  the  monthly  budget  expenditure  report.  This  report  serves  as  the  Department  Chief's 
indicator  of  the  month  to  month  status  of  the  department's  budget.     This  report  is 
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critical  to  the  monitoring  of  the  section's  compliance  with  the  department's  budget. 
This  report  is  also  provided  to  the  section  chiefs  for  the  same  reason. 

The  user  is  prompted  to  enter  the  fiscal  year  and  month  desired 
prior  to  the  output  of  this  report.  The  databases  and  appropriate  fields  necessary  to 
create  the  report  are  listed  below. 

•  APC,  extracted  from  the  Monthly  expenditure  database. 

•  Section  Description.  This  information  is  obtained  from  the  combination  of  the 
APC  database  with  the  Monthly  Expenditure  database  to  obtain  the  tide  for 
each  APC  in  the  monthly  expenditure  database. 

•  Allocation  for  the  quarter.  The  APC's  allocation  figure  from  the  allocation 
database  is  combined  with  the  monthly  expenditure  database  for  the  selected 
fiscal  year  and  quarter. 

•  Expenditures  for  the  month.  This  data  is  derived  for  each  APC  from  the 
monthly  expenditures  database. 

The  following  numbered  items,  which  clarify  the  calculated  fields 

within  the  report,  correspond  with  the  numbers  in  Figure  29. 

1  This  is  the  fiscal  year  of  the  report. 

2  This  is  the  month  of  the  report.  The  numerical  month  requested  is  converted 
to  the  name  of  the  month,  i.e.,  month  10  becomes  October. 

3  Quarter  of  the  report. 

4  Report  date  provided  by  the  system. 

5  Spent  for  Quarter.  This  field  is  calculated  by  summing  all  the  monthly 
expenditures  for  the  specified  quarter.  For  instance,  if  the  monthly  report  is  for 
November,  the  system  searches  the  monthly  expenditure  database  and  finds  all 
expenditures  for  the  first  quarter's  months;  October,  November,  and  December. 
(Note:  in  this  example,  December's  expenditures  would  be  zero.) 
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dX 

Month       JULY  ** 
Quarter      3 

"CD 

Department  of  Family  Fractlce 
Monthly  Expenditure  Report 

Qr 

Fiscal  Year 
Report  Date 

89 
7/20/89 

APC  INFORMATION 

QUARTER      ^^-^^   Y^ 

_ MONTH 

APC 

SECTION 

ALLOCATED 

SPENT 

**   PERCENT 
SPENT 

FUNDS 
PER  MONTH 

SPENT* 

*« 

percentX 

SPENT   / 

W14  0    PRIMARY  CARE 

W357    FAM  PRAC  CL 

W360    EMERG  MED  SERVICE 


4000.00    3000.00 

9000.00    9500.00 

30000.00    5000.00 


75  % 

106  % 
17  % 


1333.33 

3000.00 

10000.00 


36.36 

3100.00 

11000.00 


ft 


DEPARTMENT  TOTALS 


43000.00     17500.00 


41  % 


14333.33 


14136.36 


**  Indicates  an  overexpenditure  of  funds . 

Figure  29.    Monthly  Budget  Expenditure  Report 

6  Flag  Field.  This  field  prints  a  "**"  if  the  amount  spent  for  the  quarter  or 
month  exceeds  the  amount  allocated  for  the  quarter  or  month  (see  Note  8  below). 
This  flag  serves  as  a  visual  indicator  to  the  reader  and  highlights  probable 
problem  areas. 

7  Percent  Spent  for  Quarter.  This  field  is  computed  by  dividing  the  amount 
expended  so  far  in  the  quarter  (as  determined  in  Note  5  above)  by  the  allocation 
for  the  quarter. 

8  Funds  per  Month.  This  amount  is  computed  by  dividing  the  quarterly 
allocations  by  three  to  provide  monthly  allocations  for  the  sections. 

9  Percent  Spent  for  Month.  This  field  is  computed  by  dividing  the  amount 
expended  during  the  month  in  question  by  the  Funds  per  Month  (explained  in 
Note  8  above). 

(2)  Quarterly  Report.     Figure  30  is  an  illustration  of  the  quarterly 

budget  expenditure  report.  This  report  serves  as  the  Department  Chiefs  indicator  of  the 

status  of  funds  for  the  selected  quarter.  This  report,  like  the  monthly  report,  is  critical 

in   allowing   the    Department   Chief  to   monitor  the   sections'    compliance   with   the 

department's  budget.    This  report  is  also  provided  to  the  section  chiefs  for  the  same 

reason. 
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The  quarterly  report  is  designed  to  closely  resemble  the  monthly 
report.  This  report  remains  in  the  same  format  as  the  monthly  report,  but  excludes  all 
the  fields  relating  to  monthly  expenditures. 

The  user  is  prompted  to  enter  the  fiscal  year  and  the  quarter  desired 
prior  to  the  output  of  this  report.  The  fields  required  for  each  record  are  the  same  as 
described  in  Subsection  (1)  on  the  monthly  budget  expenditure  report. 
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Department  of  Family  Practice 
Quarterly  Expenditure  Report 


Montn 
•Quarter 


JULY 


Fiscal  Year      89 
Report  Date   07, 20 


APC  INFORMATION 


APC 


SECTION 


QUARTER 


ALLOCATED 


SPENT 


PERCENT 
SFENT 


W140 

PRIMARY  CARE 

4000.00 

3000.00 

75  % 

W357 

FAM  FRAC  CL 

9000.00 

9500.00  ** 

106  % 

W360 

EMERG  MED  SERVICE 

30000.00 

5000.00  f 

t   I 

17  % 

\ 

DEPARTMENT  TOTALS 


43000.00 


17500.00 


41  % 


**  Indicates  an  overexpenditure  of  funds. 

Figure  30.    Quarterly  Budget  Report 

The  following  numbered  items,  which  clarify  the  calculated  fields 
within  the  report,  correspond  to  the  numbers  in  Figure  30. 
1_  This  is  the  Fiscal  Year  of  the  report. 

2  This  is  the  quarter  of  the  report. 

3  Report  date  provided  by  the  system. 

4  Spent  for  Quarter.  This  field  is  calculated  by  summing  all  the  monthly 
expenditures  for  the  requested  quarter.  For  instance,  the  system  searches  the 
monthly  expenditure  database  and  finds  all  expenditures  for  the  selected  quarter's 
months,  for  each  APC. 
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5  Flag  Field.  This  field  prints  a  "**"  if  the  amount  spent  for  the  quarter  exceeds 
the  amount  allocated  for  the  quarter.  This  flag  serves  as  a  visual  indicator  to  the 
reader  and  highlights  probable  problem  areas. 

6  Percent  Spent  for  Quarter.  This  field  is  computed  by  dividing  the  amount 
expended  so  far  in  the  quarter  (as  described  in  Note  4  above)  by  the  allocation 
for  the  quarter.  This  process  is  repeated  for  each  APC. 

(3)  Fiscal  Year  Allocation  Report.     Figure  31  is  a  representation  of 

the  Fiscal  Year  Allocation  Report.  This  report  shows  the  allocation  for  each  APC  for 

each  quarter  in  the  user  selected  fiscal  year.  This  report  also  shows  the  percent  change 

between  the  previous  fiscal  year's  allocation  and  the  selected  fiscal  year's  allocation. 

This  report  provides  the  Chief  with  a  quick  look  at  the  relative  allocations  for  each  of 

his  sections  compared  with  fund  allocations  from  the  previous  fiscal  year. 

FISCAL  YEAR  ALLOCATION  REPORT 
FY  89 


DEPARTMENT  OF  FAMILY  PRACTICE  t 

COMMUNITY  MEDICINE  (TDAI 


APC    SECTION 


TI^N 


ALLOCATION        ALLOCATIONS^  ALLOCATION  ALLOCATION  TOTAL  FOR 

QUARTER  l\  CHANGE    QUARTER  2\CHANGE    QUARTER  3   CHANGE    QUARTER  4   CHANGE    FISCAL  YP   CHANGE 


W140  PRIMARY  CARE  1000.00 

W145  C,  FAM  PRAC  8000.00 

W357  FAM  PRAC  CLINIC  14000.00   -0.11 

W358  CTMS-FPC  10000.00    1.77 


516.00 

516.00 

516.00 

2550.00 

2000.00 

2000.00 

2000.00 

14000.00 

8000.00 

-0.50 

8000.00 

-0.50 

8000.00 

-0.50 

38000.00 

-0.40 

6000.00 

1.06 

6000.00 

1.06 

6000.00 

1.06 

28000.00 

1.24 

119200.00    1.04      7 


0266.00   -0.39      70266.00   -0.39      70268.00   -0.39     330000.00   -0.29 


Figure  31.    Fiscal  Year  Allocation  Report 

The  user  is  prompted  to  enter  the  fiscal  year  prior  to  the  output 
of  this  report.  The  fields  required  for  output  of  this  report  include: 

•  APC. 

•  Section  Description. 
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•  Allocations.    For  each  APC  for  the  current  year. 

•  Allocations.    For  each  APC  for  the  previous  year. 

The  following  numbered  items,  which  clarify  the  calculated  fields 
within  the  report,  correspond  with  the  numbers  in  Figure  31. 

1_  This  percentage  reflects  the  percent  change  between  the  previous  fiscal  year's 
allocation  and  the  currently  selected  fiscal  year  allocation. 

2  Totals  for  the  department.  This  number  reflects  the  total  allocation  for  the 
department  for  each  quarter  in  the  selected  fiscal  year.  This  figure  is  calculated 
from  totaling  all  quarter  allocations  for  all  of  the  APCs  within  the  APC 
Allocation  Database. 

3  In  the  cases  where  an  APC  did  not  exist  in  a  prior  year,  the  percentage  change 
field  (as  described  in  Note  1)  is  left  blank. 

(4)  Fiscal  Year  Recap.    Figure  32  provides  an  illustration  of  the  Fiscal 

Year  Recap  Report.  This  report  serves  as  the  Department  Chief's  indicator  of  the  year's 

funds  status  for  the  department.  This  report  is  critical  in  allowing  the  Department  Chief 

to  analyze  each  section's  compliance  with  the  imposed  funds  limitations.  Throughout 

the  year,  this  report  can  provide  a  quick  look  at  the  current  status  of  funds  remaining 

to  fulfill  the  needs  for  the  rest  of  the  fiscal  year. 


Fiscal  Year  :   89 

Department  of  Family  Practice 
FISCAL  YEAR  RECAP  REPORT 

Report  Date  :   7/20/89 

APC  INFORMATION 

FISCAL  YEAP   89 

RECAP 

APC 

SECTION 

1  ALLOCATED 

SPENT 

*• 

PERCENT  1 
SPENT 

ONDER  COMMITTED 
THIS  FY 

OVER  COMMITTED 
THIS  FY 

W140  PRIMAP.Y  CARE 

W357  FAM  PRAC  CL 

W3  58  CTMC-FPC 

W360  EMERG  MED  SERV 


16419 

00 

1091 

43 

6 

% 

15532 

57 

62600 

00 

62759 

02  ** 

101 

% 

15500 

00 

5630 

03 

36 

% 

/  9869 

9^ 

124000 

00 

107972 

58 

87 

% 

/  16027 

4: 

159.02 


DEPARTMENT  TOTALS 


538719.00    459885.82 


78833.4: 


**  Indicates  an  overexpenditure  of  funds. 

Figure  32.    Fiscal  Year  Recap  Report 
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The  user  is  prompted  to  enter  the  fiscal  year  desired  prior  to  the 
output  of  this  report.  The  fields  required  for  output  of  this  report  include: 

•  APC. 

•  Section  description. 

•  Allocation  for  the  quarter. 

•  Expenditure  for  the  month. 

The  following  numbered  items,  which  clarify  the  calculated  fields 

within  the  report,  correspond  with  the  numbers  in  Figure  32. 

1_  Allocated  Funds  for  FY.  This  number  represents  the  allocation  for  each  APC 
in  the  allocation  database  for  the  selected  fiscal  year.  This  number  is  computed 
by  totaling  all  quarter's  allocations  within  the  selected  fiscal  year  for  each  APC. 

2  Total  Spent  this  FY.  This  represents  the  total  amount  spent  in  the  selected 
fiscal  year  for  the  APC  .  This  number  represents  a  total  of  all  monthly 
expenditures  for  the  selected  fiscal  year  in  the  monthly  expenditure  database. 

3  Uncommitted  Funds  this  FY.  This  number  represents  the  difference  between 
Allocated  Funds  for  FY  (Note  1)  and  Total  Spent  FY  (Note  2). 

4  Over  Committed  this  Fiscal  Year.  This  column  is  printed  when  the 
uncommitted  funds  are  negative  in  the  preceeding  column  (Note  3).  It  serves  to 
flag  overcommited  sections  within  the  department. 

5  Percent  Spent  FY  .  This  column  is  calculated  by  dividing  the  Total  Spent  this 
FY  figure  (Note  2)  by  the  Allocated  Funds  for  FY  figure  (Note  1_). 

6  Department  Totals.  These  numbers,  with  the  exception  of  Percent  Spent  (Note 
5),  are  totals  of  the  respective  column  above  the  numbers.  The  Percent  Spent 
figure  is  the  total  spent  for  the  fiscal  year  divided  by  the  total  allocated  funds. 

(5)     Percent  Spent  For  Quarter  Graph  (see  Figure  33).     This  report 

provides  the  Department  Chief  with  a  graphical  portrayal  of  the  funds  remaining  for 

each  APC  for  a  selected  quarter.    This  graph  provides  a  visual  picture  of  the  current 

status  of  all  of  the  APC's  expenditures. 
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Department  of  Family  Practice 

Percent  Spent  for  Quarter 


© 


APC  SECTION 

PRIMARY  CARE 

FAM  PRAC  CL 

CTMC-FPC 

EMS 

FSO 

GOC 

POM-HC 

CTMC 

BN  AID  STATION 

FHL-HC 

CTMC  (PATH) 

CTMC  (RAD)   H 

CTMC  (PHARM) 

AMB  SVC 

CTMC  (IMMUN) 

BN  AID  STAT  (IMMUN) 

DEPARTMENT 


0%       20%      40%      60%      80%     100% 

i     i     i     i 


120%  140% 


1 1 1 1 1 

0%   20%   40%   60%   60%  100%  120%  140% 


1 


PERCENT  SPENT 


1 


Figure  33.  Percent  Spent  for  Quarter  Graph 

The  user  is  prompted  to  enter  the  fiscal  year  and  quarter  desired 
prior  to  output  of  this  report.  This  report  requires  the  following  fields  to  be  completed: 

•  APC. 

•  Section  description. 

•  Total  Expenditures  for  the  quarter  for  each  APC 

•  Allocation  for  the  quarter  for  each  APC  . 

The  following  numbered  items  correspond  to  the  numbered  items 

in  Figure  33: 

1  The  X-axis  represents  the  APC's  expenditures  for  the  quarter  on  a  scale  from 
0  to  100  percent  of  the  amount  allocated  for  the  section. 
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2  The  actual  computation  of  this  percentage  comes  from  dividing  the  total 
expenditures  for  a  section  by  the  allocation  for  that  section. 

3  APC's  active  in  the  selected  quarter  are  reported  along  the  Y-axis. 

(6)  Trend  Analysis  Graph  (see  Figure  34).  These  two  graphical  pictures 
provide  the  Chief  with  a  look  at  the  current  trend  in  expenditures  for  the  current  year 
and  the  trends  for  the  two  previous  years.  The  expenditures  are  compared  to  the 
allocations  for  the  respective  fiscal  years.  This  report  will  be  used  to  report  and  track 
the  overall  budgetary  trends  within  the  department  for  the  current  fiscal  year.  This 
report  can  be  called  up  at  any  time  during  the  current  fiscal  year. 

The  user  is  required  to  enter  the  fiscal  year  prior  to  output  of  this 
report.  The  data  fields  necessary  to  create  this  report  include: 

•  Total  Allocation  for  all  APCs  for  each  quarter  within  the  selected  fiscal  year. 

•  Total  expenditures  for  all  APCs  for  each  month  within  the  selected  fiscal  year. 
This  will  not  be  graphed  but  serves  as  the  building  block  for  the  graphing  of 
this  data  on  a  cumulative  basis. 

A  calculated  cumulative  total  for  each  of  the  above  data  fields  is 
required  to  create  these  two  graphs.  As  depicted  in  Figure  34,  one  line  is  graphed  to 
represent  the  cumulative  total  of  each  quarter's  allocation.  The  second  line  represents 
the  cumulative  total  expenditures  for  each  month. 

The  following  numbered  items  correspond  with  Figure  34. 

1.  This  line  reflects  the  cumulative  total  for  the  total  allocations  for  all  APC's 
reported  for  the  selected  fiscal  year  in  the  APC  Allocation  Database. 

2  Each  tick  mark  on  the  line  corresponds  to  the  actual  total  expenditure  for  all 
APCs  for  the  given  month  on  the  X  axis. 
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Figure  34.  Trend  Analysis  Graph 
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3  This  graph  represents  a  long  term  trend  analysis  of  department  wide 
expendittires.  The  system  uses  the  current  fiscal  year's  expenditures  and  the  two 
previous  year's  expenditures  to  create  this  graph 

4  The  fiscal  year  of  the  information  graphed. 

5  Quarter  allocations  are  plotted  on  the  FY  graph  by  dividing  the  quarterly 
allocation  into  three  equal  monthly  allocations  (done  within  the  department). 
These  monthly  allocations  are  then  graphed  on  a  cumulative  basis. 

6  The  percent  of  allocation  is  computed  by  dividing  the  expenditures  for  the 
month  by  the  allocation  for  the  month. 

2.      Equipment  Information  System  (see  Program,  Appendix  D) 

Figure  35  is  the  UCD  describing  the  proposed  Equipment  Information 
System.  As  shown  in  the  diagram,  initial  equipment  requirements  are  identified  with 
the  department's  Resource  Information  Report  (RIR).  The  RIR  is  shown  in  Figure  36. 
This  report  is  completed  by  the  sections  and  submitted  to  the  department  NCOIC.  In 
addition  to  new  equipment  requirements,  the  RIR  is  also  the  medium  for  updating 
previously  submitted  equipment  requirements.  The  information  contained  in  the  RIR 
is  used  by  the  department  to  update  the  equipment  procurement  database.  As  shown 
in  Figure  36,  the  RIR  is  also  the  medium  for  collecting  section  personnel  information, 
i.e.,  gains,  losses,  and  changes.  The  personnel  portion  of  the  RIR  is  discussed  in 
Section  3,  Personnel  System. 
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Figure  35.  Equipment  Information  System  User  Concept  Diagram 
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Figure  36.  Resource  Information  Report  (RIR) 
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a.      Data  Structures 

The  Equipment  System  consists  of  two  databases.  The  primary  database 
maintains  the  active  department  equipment  requirements  and  contains  the  following  data 
fields: 

•  Equipment  Code  Number.  This  number,  assigned  by  the  system,  uniquely 
identifies  each  equipment  item  in  the  database. 

•  Section  Code.  Explained  in  Section  1,  Budget  System. 

•  Date  of  Request.  The  date  equipment  is  requested  by  the  section. 

•  Item  Description.  This  is  a  short  description  of  each  equipment  item  identified 
in  the  database. 

•  Type  of  Request.  The  equipment  requested  will  be  one  of  four  types, 
MEDCASE,  CEEP,  CAPR,  or  other  as  described  in  Chapter  IV. 

•  Priority.  The  priority  number  is  a  ranking  of  all  of  the  equipment  to  indicate 
the  relative  priority  of  each.  The  Department  Chief  assigns  the  priority  to  all 
department  equipment  using  the  priority  worksheet  described  in  the  Outputs 
section  below. 

•  Urgency  Code.  The  urgency  code  indicates  how  soon  the  equipment  is  needed 
by  the  section. 

•  Quantity. 

•  Unit  Price. 

•  Extended  Price.    Quantity  *  Unit  Price. 

•  Status  of  Procurement.  The  status  of  the  procurement  is  indicated  by  one  of 
five  codes  to  show  where  each  equipment  request  is  in  the  procurement 
process.    The  five  codes  and  their  meaning  are  listed  below: 

PYV  Paperwork  is  being  prepared  by  the  section  requesting  the  equipment. 

RM  RMD  is  processing  the  equipment  request. 

AP  RMD  has  approved  the  equipment  procurement. 

OO  The  section  as  put  the  equipment  on  order. 

RC  The  equipment  has  been  received  by  the  section. 

•  Comments. 
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The  second  database  maintains  the  historical  information  on  equipment 

previously  procured  by  the  department  and  consists  of  the  following  data  fields: 

Section  Code. 

Item  Description. 

Type  of  Request. 

Quantity. 

Extended  Price. 

Date  of  Request.  Taken  from  primary  database  described  above. 

Transfer  Date.  The  date  the  item  was  transferred  to  the  historical  database 
(upon  receipt  of  the  equipment). 

Months  to  Complete  Procurement.  The  difference  between  the  date  of  request 
and  the  transfer  date. 

Comments. 

b.      Data  Inputs 

The  Equipment  System  menu  hierarchy  chart  is  shown  in  Figure  37. 
The  menu  system  allows  the  user  to  update  the  equipment  database,  print  reports,  and 
archive  completed  equipment  procurements  in  the  historical  database.  Users  enter  new 
equipment  requirements  into  the  primary  equipment  database  using  the  input  screen 
shown  in  Figure  38.  This  screen  presents  all  of  the  data  fields  necessary  for  user  input 
and  displays  the  various  codes  needed  for  the  specific  data  fields. 

To  change  or  remove  equipment  from  the  database,  the  user  selects  the 
appropriate  menu  item  and  is  then  prompted  to  enter  the  equipment  code  number  or 
the  section  code  to  identify  the  equipment  to  be  changed  or  removed.  If  the  user  does 
not  know  the  equipment  code  number,  he  or  she  can  enter  the  section  code.    A  list 
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Figure  37.    Equipment  Menu  Tree 
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of  all  equipment  requirements  for  that  section  is  presented.  The  user  is  then  asked  to 
enter  the  record  number  (displayed  to  the  left  of  each  equipment  item)  of  the  desired 
equipment  record  to  change.  When  changing  equipment  data,  the  user  is  presented 
with  the  same  screen  discussed  above  for  new  data  entry. 


ENTER         NEW         EQUIPMENT 

D 

ATA 

EQUIPMENT    CODE    #         ■■ .  ■ 

SECT 

DATE                  ITEM   DESCRIPTION                    TYPE         URGENCY 

■  ■■    wtmmmmmmmm    wm 

STATUS    CODE                                       COMMENTS 

QTY 

UNIT    PRICE 

■■■■■■ 

URGENCY  CODES 


Needed  Now 

1  Year 

2  Years 

3  Years 
Not  Urgent 


TYPE  OF  REQUEST  CODES 


MEDC  MEDCASE 

CEEP  CEEP 

CAPR  CAPR 

OTHE  OTHER 


STATUS  CODES 


PW  Paperwork 
RM  RMD  Process 
AP  Approved 
CO  On  Order 
RC  Received 


Figure  38.    Equipment  Input  Screen 

The  user  is  allowed  to  update  the  priorities  on  the  equipment  list. 
Priority  changes  are  obtained  from  the  priority  worksheet  (discussed  in  the  Output 
section  below).  The  Department  Chief  reviews  all  equipment  requests  and  completes 
the  priority  worksheet  to  identify  overall  department  priorities.  The  database  is  then 
updated  with  the  new  priorities.  After  selecting  the  equipment,  the  user  is  presented 
with  a  review  screen  similar  to  that  described  in  Section  C  of  this  chapter.  The  fields 
displayed  correspond  to  the  priority  worksheet  to  simplify  user  input  and  are  listed 
below: 

•  Equipment  Code  Number. 

•  Type  of  Request. 

•  Section  Code. 
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•  Item  Description. 

•  Urgency  Code. 

•  Priority.  The  Department  Chief's  numerical  ranking  for  the  item. 

•  Quantity. 

•  Unit  Price. 

The  user  is  allowed  to  enter  the  changes  directly  to  the  review  screen. 
When  equipment  status  changes,  e.g.,  an  equipment  requisition  is  submitted  or 
equipment  is  received,  the  sections  are  required  to  indicate  this  on  the  RIR  and  submit 
it  to  the  department  NCOIC.  These  status  changes  are  then  entered  into  the  database 
using  the  input  screen  shown  in  Figure  39.  This  screen  is  similar  in  format  to  the 
Status  Update  section  on  the  RIR  to  simplify  user  data  entry. 


SECTION 

FPC 

EQUIP  CODE 
9010.01 

ITEM  DESCRIPTION 
BREAST  PUMP 

COMMENTS 

QTY 
2 

UNIT  PRICE 
1300.00 

STATUS 
PW 

Press  ESC  to  abort  editing,  ENTER  to  complete  changes. 

Figure  39.    Status  Update  Screen 
c.      Outputs 

(1)  Review  Equipment  List.  The  format  of  the  review  screen  is 
discussed  in  Section  B  above.  All  of  the  equipment  database  fields  are  listed  on  the 
review  output  scieen.  The  user  can  scroll  left  and  right,  up  and  down,  to  view  or 
change  all  fields  for  each  record. 
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(2)  Department  Equipment  Report  (see  Figure  40).  The  department 
equipment  report  is  a  complete  equipment  requirements  listing  for  the  department.  All 
of  the  fields  in  the  equipment  database  are  used  to  produce  this  report.  The  user  is 
altewed  to  choose  one  of  three  sort  options.  The  flexibility  to  select  the  sort  option 
makes  it  easier  to  highlight  those  aspects  of  equipment  procurement  most  important  to 
the  Department  Chief.    Each  sort  option  is  discussed  below: 

•  Sorting  by  Cost.  The  equipment  list  is  sorted  by  the  extended  price  field, 
from  high  values  to  low. 

•  Sorting  by  Urgency.  The  equipment  list  is  sorted  by  the  urgency  code,  from 
zero  (0)  for  immediate  equipment  requirements  to  four  (4)  for  non-urgent 
requirements.  Within  each  urgency  code  section  the  equipment  is  further 
sorted  by  section  code  and  extended  price  (from  high  to  low). 

•  Sorting  by  Status.  The  status  sort  option  groups  the  equipment  information 
by  each  of  the  five  status  codes.  Each  group  is  further  sorted  by  section  code 
and  extended  price  (from  high  to  low). 


* — (2) 

TYPE    SORT:    COST  V_V — - 

_____ -^3u= 

~ DEPARTMENT 

EQUIPMENT    REPORT 

GX 

5ATE: 

7/20/89 
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DESCRIPTION 
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QTY 

UNIT 
PRICE 

EXTENDED 
PRICE 

ACCUMULATED 
TOTALS 

STAT 

COMMENTS 

90LV.01    TFC  01/10/e9    BEDPAN 

9025.20    EMS  01/20/89    SPIT    COP 

83C.89    CTM  12/15/88    MICROCOMPUTER 

9101'.  60    CFP  04/10/89    GAMMA    CAMERA 


MEDC  2  1 

OTHE  5  2 

CAPR  9  1 

CEEP  4  1 


2  5200.00  10400.00  10400.00 

5  1000.00  5000.00  15400.00 

1  3000.00  3000.00  18400.00 

1  1000.00  1000.00  19400.00 


Figire  40.    Department  Equipment  Report 
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FW 

OO    BACKORD 

OO    BACKORD 

AP 


The  following  numbered  items  correspond  to  the  numbers  in  Figure 

40  and  explain  certain  portions  of  the  report. 

|  The  system  date  is  printed  at  the  top  of  the  report. 

2  The  type  of  sort  indicates  how  the  equipment  list  has  been  sorted,  by  COST, 
URGENCY,  or  STATUS. 

J  The  format  of  the  fields  listed  across  the  top  remains  the  same  regardless  of 
the  sort  option  chosen. 
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4  The  cumulative  total  is  calculated  by  adding  each  successive  extended  price  to 
the  previous  cumulative  total. 

(3)  Equipment  Type  Report   (see  Figure  41).     The  equipment  type 

report  is  a  listing  of  the  equipment  requirements  for  one  of  the  equipment  types,  either 

MEDCASE,  CEEP,  CAPR,  or  OTHER.    The  user  selects  the  type  of  equipment  he  or 

she  wants  listed  from  the  menu.    All  of  the  fields  in  the  equipment  database  are  used 

to  produce  this  report.    The  user  is  allowed  to  choose  one  of  two  sort  options.    Each 

sort  option  is  discussed  below: 

•  Sorting  by  Cost.  The  equipment  list  is  sorted  by  the  extended  price  field, 
from  high  values  to  low. 

•  Sorting  by  Priority.  The  equipment  list  is  sorted  by  the  priority  code,  from 
one  for  highest  priority  to  the  lowest  existing  priority  in  the  database.  Within 
each  priority  section  the  equipment  is  further  sorted  by  section  code  and 
extended  price  (from  high  to  low). 


TYPE 

EQUIPMENT:  CEEPV_-/ 

Q 

'      EQUIPMENT  TYPE  REPORT 

G 

DATE:  7/25/89 

PRI 

SECT 

REQ 
DATE 

DESCRIPTION 

URG 

QTY 

UNIT 
PRICE 

EXTENDED 
PRICE 

ACCUMULATED 
TOTALS 

STAT 

COMMENTS 

1  FPC  01/10/89  INSUFFLATOR  1  2  4800.00  8800.00  8800.00  PW 

2  EMS  01/20/89  MICROTOME  2  5  4990.00  24950.00  33750.00  OO     BACKORD 

3  CTM  12/15/88  FLURO-LITE  1  1  1149.00  1149.00  34899.00  OO     BACKORD 

4  CFP  04/10/89  PLASMA  BATH  1  1  1500.00  1500.00  36399.00  AP 

© 
Figure  41.    Equipment  Type  Report 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 

41  and  explain  certain  portions  of  the  report. 

1  The  system  date  is  printed  at  the  top  of  the  report. 

2  The  type  of  equipment  indicates  which  equipment  type  is  listed  in  the  report, 
either  MEDCASE,  CEEP,  CAPR,  or  OTHER. 

3  The  format  of  the  fields  listed  across  the  top  remains  the  same  regardless  of 
the  sort  option  chosen. 

4  The  cumulative  total  is  calculated  by  adding  each  successive  extended  price  to 
the  previous  cumulative  total. 
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(4)  Equipment  Priority  Worksheet  (see  Figure  42).  The  priority 
worksheet  is  used  by  the  Department  Chief  in  a  meeting  with  each  of  his  section 
chiefs.  In  this  meeting,  the  priority  of  all  of  the  department's  equipment  requirements 
is  determined  and  annotated  on  the  priority  worksheets  for  each  equipment  type.  These 
worksheets  are  then  used  to  update  the  priorities  in  the  equipment  database. 
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Figure  42.    Equipment  Priority  Worksheet 


<i> 


The  data  fields  necessary  to  produce  the  priority  worksheet 


are 


listed  below: 


Type  of  Equipment. 

Equipment  Code  Number. 

Section  Code. 

Item  Description. 

Priority. 

Urgency  Code. 

Quantity. 

Unit  Price. 

Extended  Price. 

Comments. 

The  following  numbered  items  correspond  to  the  numbers  in 
Figure  42  and  explain  certain  portions  of  the  report. 


123 


1.  The  system  date  is  printed  at  the  top  of  the  report. 

2  The  type  of  equipment  indicates  which  equipment  type  is  listed  in  the  report, 
either  MEDCASE,  CEEP,  CAPR,  or  OTHER. 

3  A  fill  in  section  is  provided  to  allow  the  Department  Chief  to  enter  the  updated 
priorities. 

(5)    Equipment  Historical  Report  (see  Figure  43).  Once  equipment 

is  received,  the  data  referencing   it  can  be  archived  from  the  primary  equipment 

database  to  the  historical  database.     All  of  the  historical  database  fields  are  used  to 

produce  the  equipment  historical  report.    The  report  can  be  sorted  either  by  section  or 

by  equipment  type.    Within  each  of  these  sort  options  the  list  is  further  sorted  by  the 

extended  price  field,  from  high  to  low. 
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1 
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1000.00 
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1000.00 

Figure  43.    Equipment  Historical  Report 

The  following  numbered  items  correspond  to  the  numbers  in 

Figure  43  to  explain  the  report  information. 

1_  The  transfer  date  is  automatically  entered  into  the  database  using  the  system 
date  when  the  data  is  archived. 

2  The  months  to  complete  the  procurement  are  calculated  by  subtracting  the 
transfer  date  from  the  original  request  date. 

3  Subtotals  for  each  section  or  equipment  type  group  are  shown  for  the  extended 
price  field  and  is  obtained  by  totaling  the  extended  prices  for  the  respective 
group. 
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(6)  Historical  Summary  Report  (see  Figure  44).  The  historical 
summary  report  displays  summary  statistical  information  about  the  data  in  the  historical 
database.  The  Department  Chief  can  use  the  summary  report  to  determine  the 
department's  history  of  equipment  procurement  in  terms  of  the  number  of  equipment 
requests,  average  costs  of  the  equipment  requested,  the  type  of  equipment  requested, 
and  the  average  length  of  time  to  obtain  equipment.  The  historical  database  fields 
necessary  to  create  the  summary  report  are  listed  below. 

Section  Code. 

Type  of  Request. 

Quantity. 

Extended  Price. 

Date  of  Request. 

Transfer  Date. 

Months  to  Complete  Procurement. 

The  following  numbered  items  correspond  to  the  numbers  in 
Figure  44  and  explain  the  method  used  to  produce  the  summary  report  information. 

1  The  earliest  date  of  request  and  the  latest  date  of  request  contained  in  the 
database  are  listed  at  the  top  of  the  report. 

2  The  total  number  of  requests  for  each  type  of  equipment  are  calculated  by 
adding  the  total  quantities  of  equipment  procured  for  each  equipment  type. 

3  The  average  cost  of  each  equipment  type  is  calculated  by  dividing  the  total 
extended  price  for  the  equipment  type  group  by  the  total  number  of  requests  for 
that  equipment  type  group. 

4  The  average  time  to  complete  an  equipment  procurement  is  calculated  by 
averaging  all  of  the  figures  for  the  number  of  months  to  complete  each 
procurement  for  each  equipment  type. 
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5  The  total  number  of  requests  for  each  type  of  equipment  is  summed  for  each 
section. 

6  The  average  cost  for  each  type  of  equipment  is  calculated  for  each  section  by 
dividing  the  total  cost  of  the  equipment  type  requests  for  a  section  by  the  total 
number  of  requests  for  that  equipment  type  for  the  section. 


HISTORICAL  SUMMARY  REPORT 


REQUESTS  BY  TYPE 

TYPE  REQUEST 
CAPR 
MEDC 
CEEP 

#  REQUESTS  BY  SECTION 
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EARLIEST  REQ  DATE:  1/13/86 
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Figure  44.    Historical  Summary  Report 

3.      Personnel  Information  System  (see  Program,  Appendix  E) 

Figure  45  is  the  user  concept  diagram  for  the  personnel  information  system. 
This  system  interfaces  the  four  major  personnel  subsystems  identified  in  Chapter  IV. 
These  information  subsystems  include: 

•  Department  Personnel  Information  Subsystem  (including  personal  data). 

•  Table  of  Distribution  and  Allowances  Subsystem. 

•  Leave  and  Absence  Recordkeeping  Subsystem. 

•  Continuing  Medical  Education  (CME)  Budget  Subsystem. 


126 


Figure  45.  Personnel  Information  System  User  Concept  Diagram 
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The  consolidation  of  all  four  personnel  subsystems  under  one  major  system 
simplifies  the  transfer  and  maintenance  of  the  six  data  files  necessary  to  maintain  the 
data.  All  personnel  inputs,  processing,  and  outputs  are  captured  within  a  single  series 
of  operations  without  requiring  the  user  to  leave  the  current  application  environment. 

a.      Data  Structures 

Figure  46  depicts  the  various  database  files  required  to  support  the 
personnel  information  system.  This  figure  shows  how  the  file  that  represents  a  person 
within  the  department  serves  as  the  pivotal  point  for  the  interrelation  of  all  of  the 
personnel  files. 
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Figure  46.    Personnel  Data  Structures 
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The  key  field  identified  throughout  the  database  is  the  Personnel 
Identification  Code  as  described  below.  This  code  is  already  used  in  the  current  system. 
It  is  recognized  as  the  method  by  which  personnel  data  should  be  maintained 
throughout  the  department. 

The  personnel  file,  which  represents  an  individual  assigned  to  the 

department,  contains  the  following  fields: 

•  Personnel  Identification  Code.  This  code  is  derived  from  the  first  letter  of  an 
individual's  last  name,  combined  with  the  last  four  numbers  of  their  social 
security  number. 

Last  Name. 

First  Name  and  Middle  Initial. 

Rank. 

Branch  of  Service  (accepted  military  abbreviations  e.g.,  Medical  Corps  (MC), 
Army  Nurse  Corps  (AN),  etc.). 

Military  Occupational  Specialty  Code. 

Arrival  Date  within  the  Department. 

Anticipated  Date  of  PCS  (if  known). 

Currently  assigned  TDA  Paragraph  Number. 

Currently  assigned  TDA  Line  Number. 

Currently  assigned  TDA  Position  Number.  If  the  person  is  carried  as  excess, 
this  number  will  be  99. 

Doctor  Status  (if  appropriate).  This  code  serves  to  track  only  the  current 
training  status  of  doctors  in  the  residency  program.  The  codes  used  are;  (1) 
Third  Year  Residency,  (2)  Second  Year  Residency,  (3)  First  Year  Residency 
(Student). 
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The  personal  information  database  file  serves  as  the  repository  of 

sensitive  information  about  an  assigned  individual.  Each  record  contains: 

Personnel  Identification  Code.  This  code  serves  to  relate  this  file  to  the 
personnel  file. 

Local  Home  address. 

City  of  Home  address. 

State. 

Spouse's  first  name  (if  appropriate). 

Children's  names,  followed  by  their  ages  (if  appropriate). 

Home  telephone  number. 

Date  of  rank. 

Personal  Comments. 

The  Table  of  Distributions  and  Allowances  (TDA)  database  file  reflects 
the  current  positions  available  as  obtained  from  the  most  up  to  date  TDA  for  the 
department.  Each  record  contains  the  following  fields: 

TDA  Paragraph  Number. 

TDA  Line  Number. 

TDA  Position  Number. 

TDA  Official  Job  Title. 

The  APC  that  relates  to  this  particular  position. 

The  authorized  branch  of  service  of  this  position. 

The  authorized  rank  or  grade  for  this  position. 

The  authorized  Military  Occupational  Specialty  for  this  position. 
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•  Authorized  field.  This  field  is  used  to  determine  if  the  position  is  an 
authorized  position  under  the  current  TDA.  This  position  could  actually  be 
required  under  the  TDA  but  not  authorized  under  peacetime  conditions.  This 
is  a  common  occurrence  in  TDAs  in  the  military. 

The  Continuing  Medical  Education  funds  allocation  database  records  the 

CME  allocation  for  each  fiscal  year.  Each  record  contains  the  following  fields: 

•  Fiscal  Year. 

•  Allocation  for  the  fiscal  year  in  dollars. 

The  Continuing  Medical  Education  request  database  records  the  doctors' 
requests  for  CME  funded  education.  Each  doctor  can  have  several  active  CME  requests 
within  this  database.  Each  record  contains  the  following  fields: 

Personnel  Identification  Code. 

Fiscal  Year  of  the  request. 

Type  Request.  The  CME  request  can  be  one  of  the  following  types  of 
requests:  (C)  Conference/Meeting  Travel,  (G)  General  Mission  Travel,  (B) 
Board  Certification. 

Start  Date  of  Travel. 

End  Date  of  Travel. 

Duration  of  travel.  This  field  is  computed  by  determining  the  number  of  days 
between  the  start  date  and  the  end  date.  This  data  is  used  in  the  statistical 
summary  reports  described  in  Section  3.c,  Outputs,  below. 

Location  or  Destination. 

Purpose  of  travel.  The  title  of  the  conference  or  the  specific  purpose  of  the 
request. 

Travel  Mode.  Travel  can  either  be  by  (A)  aircraft,  (P)  privately  owned  vehicle, 
or  (G)  government  provided  ground  transportation.  This  is  used  in  the 
computation  of  the  costs  involved  in  the  travel. 
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•  Travel  cost  (Actual  or  estimated  cost  depending  on  the  Costing  Code  described 
below). 

•  Per  Diem  Cost  (Actual  or  estimated  cost  depending  on  the  Costing  Code 
described  below). 

•  Registration  Fee  for  the  Conference  (Actual  or  estimated  cost  depending  on 
Costing  Code  described  below). 

•  Reimbursable  expenses  (Actual  or  estimated  cost  depending  on  Costing  Code 
described  below). 

•  Total  Cost  of  travel.  This  field  is  calculated  by  adding  the  Travel  cost,  Per 
Diem  cost,  Registration  Fee,  and  Reimbursable  expenses  fields  (Actual  or 
estimated  total  cost  depending  on  the  Costing  Code  of  the  related  fields). 

•  Costing  Code.  This  code  differentiates  between  an  estimated  total  cost  and  the 
actual  costs.  The  actual  costs  are  identified  once  the  travel  has  been  completed 
and  the  travel  claim  voucher  is  received  by  the  department. 

The  Absence  database  maintains  the  record  of  all  requested  leaves  or 

other  absences,  e.g.,  permissive  TDY,  emergency  leave.  This  database  does  not  record 

the  CME  requests  discussed  in  the  CME  request  database  section.  Each  record  contains 

the  following  fields: 

•  Personnel  Identification  Code. 

•  Fiscal  Year  of  request. 

•  Type  of  request.  (L)  Ordinary  Leave,  (P)  Permissive  TDY,  (E)  Emergency 
Leave,  (S)  Sick  Leave  or  Convalescence  leave,  (T)  Temporary  Duty,  or  (O) 
other  type  of  unspecified  absences. 

•  Start  Date  of  Absence. 

•  End  Date  of  Absence. 

•  Duration  of  absence.  This  field  is  computed  by  determining  the  number  of 
days  between  the  start  date  and  the  end  date. 

•  Comments  on  special  circumstances. 
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b.      Data  Inputs 

The  Personnel  Information  System  menu  hierarchy  chart  is  shown  in 
Figure  47.  This  menu  system  allows  the  user  to  update  the  personnel  system  databases 
in  the  following  areas: 

•  Add,  change  or  remove  records  in  the  personnel  and  personal  database. 

•  Add,  change  or  remove  records  in  the  Table  of  Distributions  and  Allowances 
database. 

•  Update  the  Personnel  Files  from  information  provided  on  the  Resource 
Information  Report  explained  in  the  equipment  information  system  Section  (2). 

•  Add,  change,  or  remove  records  in  the  Continuing  Medical  Education  request 
and  funds  allocation  databases.  The  user  can  also  print  the  two  required  reports 
for  CME  fund  monitoring. 

•  Add,  change  or  remove  records  from  the  absence  database. 

The  following  sections  describe  the  major  data  entry  requirements  for 
the  personnel  system.  The  common  data  entry  requirements  are  described  in  the  first 
section.  This  description  is  followed  by  the  data  input  requirements  for  each  of  the 
major  input  submenus  depicted  in  Figure  47. 

(1)  Common  Input  Requirements.  In  most  of  the  submenus,  the  user 
is  required  to  enter  a  personnel  identification  code  (PIC).  The  standardized  entry  screen 
discussed  in  Section  C.2.a,  Input  Screens,  is  used  for  this  input.  The  system  then 
verifies  the  PIC  entered  against  the  personnel  file.  If  the  PIC  is  found  in  the  database, 
the  user  is  presented  with  the  following  confirmation  screen. 
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Figure  47.    Personnel  System  Menu  Hierarchy  Chart 
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THIS  IS  THE  PERSON  WHOSE  ID  CODE  IS  MM 
LAST  NAME  HDHBI    FIRST  NAME  ■■BHB    RANK  B 
OCCUPYING  TDA  PARAGRAPH  Hg  LINE  ■   POSITION  fi 
««««SYSTEM  MESSAGE  DEPENDING  ON  TYPE  OF  REQUEST»»»» 

This   confirmation   screen  allows   the  user  to   determine   if  the 

requested  PIC  is  correct.  This  type  of  confirmation  prevents  the  user  from  entering  a 

wrong  or  inappropriate  PIC  that  would  destroy  the  integrity  of  the  database.  If  the 

identification  code  is  not  found,  a  warning,  "ID  Code  not  found!  Press  return  to 

continue...",  is  displayed.  The  system  then  gives  the  user  the  option  to  search  for  a  PIC 

by  entering  the  last  name  of  the  person.  All  records  with  the  requested  last  name  are 

displayed  as  shown  below  and  the  user  is  allowed  to  pick  the  identification  code  of  the 

correct  person  from  the  list. 

LAST  NAMEFTRST  NAME  ID  CODE 
SMITH  JOHN  E.  S2356 

SMITH  BECKY  K.      S9999 

ENTER  THE  ID  CODE  OF  THE  PERSON  DESIRED:  ^M 

An  appropriate  modification  to  this  screen,  if  supported  in  the 
application  program,  would  be  the  ability  to  select  a  record  by  highlighting  the  record 
desired  and  pressing  the  return  key.  This  process  would  eliminate  the  possibility  of 
keying  errors  being  introduced  by  the  user. 

If  the  user  is  requested  to  enter  information  on  a  TDA  position, 
the  screen  shown  below  is  presented  to  the  user. 
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WHAT  POSITION  WILL  THIS  PERSON  OCCUPY 
OR  ENTER  A  ZERO  (0)  TO  QUIT 

TDA  Paragraph  Number    Ml 

TDA  Line  Number  BQ 

TDA  Position  Number     ■ 

Another  feature  that  would  enhance  this  input  would  be  the  addition 
of  the  ability  to  call  up  all  TDA  positions  that  are  unoccupied.  The  user  would  then 
be  allowed  to  select  a  TDA  position  by  highlighting  a  particular  position  from  among 
those  depicted  on  the  screen.  This  enhancement  will  make  the  following  two  screens 
unnecessary. 

The  system  then  verifies  the  requested  TDA  position  with  the  TDA 
database  and  if  the  position  is  found  to  exist  in  the  database,  the  user  is  presented  with 
the  following  standard  TDA  position  screen. 

POSITION  CHOSEN: 

Job  Title  :  WE&8BBBM3B3BBB3M 

Authorized  Branch  :  B  Authorized  Grade  :  ■ 

Authorized  MOS        :  m        Authorized  Position  :  YES 
This  screen  also  converts  the  authorized  position  field  from  its  coded  value  to  the 
correct  YES  or  NO  answer  depending  on  the  contents  of  this  field. 

In  the  cases  where  a  TDA  position  is  requested  and  is  found  to 
already  be  occupied  by  someone  else,  the  warning  screen  shown  below  is  presented  to 
the  user. 
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THE  POSITION  IS  ALREADY  OCCUPIED  BY: 

Last  Name 
First  Name 
Rank  :  | 

The  user  is  then  given  the  following  choices. 

YOU  NOW  HAVE  THE  FOLLOWING  CHOICES: 

1.  MOVE  THE  PERSON  FOUND  IN  THE  POSITION  TO  EXCESS  (POSITION 
CODE  99)  AND  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THE 
POSITION  YOU  ORIGINALLY  REQUESTED. 

2.  PLACE  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THIS 
POSITION  AS  EXCESS  (OVERSTRENGTH,  POSITION  CODE  99). 

3.  TRY  ANOTHER  POSITION. 
ENTER  YOUR  CHOICE  (1-3)  :  | 

(2)  Enter,  change,  or  remove  personnel  from  the  personnel  database. 
As  discussed  earlier,  the  user  is  first  requested  to  enter  the  identification  code  of  the 
individual  to  add,  change,  or  remove  from  the  personnel  file.  In  all  of  these  cases,  the 
system  first  checks  the  personnel  file  for  the  requested  identification  code.  If  the  code 
is  already  in  use,  and  the  user  is  trying  to  enter  this  identification  code  to  add  a  new 
person  to  the  personnel  file,  the  standard  confirmation  screen  is  displayed  with  the 
message  "ID  CODE  REQUESTED  IS  ALREADY  USED  BY  THE  PERSON  SHOWN 
ABOVE"  and  the  user  is  prompted  to  try  a  different  code.  When  the  user  is  updating 
or  removing  someone  already  in  the  personnel  file,  this  PIC  check  serves  to  confirm 
the  identification  code  already  exists  in  the  file  and  warns  the  user  if  it  is  not  found. 
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If  the  identification  code  is  not  found,  the  system  gives  the  user  the  same  options  as 
described  in  the  general  input  screens  discussed  earlier. 


UPDATE  PERSONNEL 


ID   CODE    is    W1456 

Last    Name 

First 

Name      MI 

RANK 
MM 

BRANCH 
■ 

MOS 

RMfiHHHIIIIiHlllMSM 

m^HH  3889 

mmm 

Anticipated   Date    of    Loss 

-  M  M  W 

INDIVIDUAL  IS  ASSIGNED  TO  TDA  POSITION 


TDA  Paragraph  Number  is  250 
TDA  Line  Number  is  10 
TDA  Position  Number  is  99 


NOTE:  If  Position  Number  is  99,  the  Individual  is  carried  as  excess 

Figure  48.    Personnel  Input  Screen  Format 

If  the  user  is  adding  or  changing  information  in  the  personnel 
database,  the  system  requests  the  new  position  before  displaying  a  blank  data  entry 
screen  format.  This  action  allows  the  system  to  verify  that  the  TDA  position  is  valid 
and  is  not  already  occupied  by  someone  else.  If  the  position  is  occupied,  the  standard 
choice  screen  as  discussed  earlier  is  displayed  and  the  user  must  choose  an  appropriate 
course  of  action.  Once  they  have  selected  a  course  of  action,  the  system  then  allows 
access  to  the  personnel  database.  The  screen  depicted  in  Figure  48  is  the  standard  input 
screen  for  personnel  information.  This  screen  does  not  allow  the  user  to  either  change 
the  identification  code  or  the  position  information,  thus  preventing  the  user  from 
circumventing  the  integrity  checks  already  accomplished  by  the  system. 

Once  the  user  has  entered  information  into  the  personnel  file,  he 
or  she  is  given  the  choice  to  enter  data  into  the  personal  file.  This  data  entry  format 
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is  displayed  in  Figure  49.  This  screen  includes  the  privacy  act  statement  to  remind  the 
user  of  the  sensitive  nature  of  this  information. 


This  is  the  personal  information  for  ID  CODE  S7395 


PRIVACY  ACT  STATEMENT 
PRINCIPLE  PURPOSE:  To  maintain  personal  information  on  individuals  assigned  to 
this  command  to  facilitate  counseling,  emergency  notification,  and  social 
event  information. 

WARNING:  This  information  is  of  a  highly  sensitive  nature  and  should  not  be 
provided  to  anyone  outside  of  the  chain  of  command  without  approval. 


Address 

City,    State,    Zip   Code 

Date    of    Rank 
Wife's    Name   ■■MM  Children's    Names  'Ages 

Comments  BHIHWIBffltf'I'lirt'l  —*■»»— bbmbmhh 


Figure  49.    Personal  Information  Data  Entry  Screen 

If  the  user  desires  to  delete  someone  from  the  personnel  database, 
the  identification  code  entered  by  the  user  is  used  to  find  the  right  record.  The  screen 
depicted  in  Figure  48  is  displayed  with  the  message,  "IS  THIS  THE  PERSON  YOU 
WANT  TO  DELETE?  (Y/N)"  |  ",  included  on  the  screen.  This  allows  the  user  to 
confirm  the  information  about  the  person  they  desire  to  delete.  If  the  user  deletes  the 
person,  the  system  then  purges  all  the  files  in  the  personnel  system  which  have  the 
requested  identification  code.  Several  databases  are  affected:  the  personnel  database;  the 
personal  database;  the  CME  request  database;  and  the  absence  database. 

(3)  Enter,  change,  or  remove  TDA  information.  The  user  gains  access 
to  the  TDA  database  by  initially  entering  the  position  they  desire  to  add,  change  or 
remove  in  the  position  entry  format  described  earlier.  In  the  case  where  the  user  is 
adding  a  new  position,  this  information  allows  the  system  to  verify  that  the  TDA 
position  requested  does  not  already  exist  in  the  database.  If  the  user  is  modifying  an 
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already  existing  TDA  record,  this  information  is  used  to  locate  the  record  or  warn  the 
user  that  the  position  entered  does  not  exist  in  the  database. 


TABLE  OF  DISTRIBUTION  AND  ALLOWANCES 


TDA  Listing 


Paragraph  Number 
Line  Number 
Position  Number 

258 
10 
01 

POSITION  TITLE 

job  Title  ■■HSSBHHHSPi 

POSITION 

CHARACTERISTICS 

APC  Code 

mm 

Authorized 

Branch 

Authorized 

Grade 

Authorized 

MOS         *"■'■" 

Position  Authorized 

1=YES 

0=NO 

Figure  50.    Table  of  Distribution  and  Allowances  Input  Screen 

The  system  must  determine  the  authorized  status  of  the  position. 
If  the  position  is  new  to  the  database,  the  user  is  required  to  answer  the  prompt,  "IS 
THIS  AN  AUTHORIZED  POSITION?  (Y/N)  |  ".  If  the  user  answers  yes,  the  system 
automatically  replaces  the  authorization  code  with  a  one,  otherwise  the  code  is  replaced 
with  a  zero.  If  the  user  is  modifying  an  already  existing  database,  the  system  uses  the 
existing  code  to  ask  the  user  if  they  desire  to  change  the  current  authorized  status  to 
the  opposite  status.  For  instance,  if  the  authorized  code  is  zero  (0)  (unauthorized),  the 
message,  "DO  YOU  WANT  TO  CHANGE  THIS  POSITION  TO  AN  AUTHORIZED 
STATUS?  (Y/N)  |  ",  is  displayed. 

If  the  user  desires  to  delete  a  position,  the  format  depicted  in 
Figure  50  is  used,  but  it  includes  a  message  to  verify  if  the  user  desires  to  delete  the 
displayed  record.  If  the  record  is  deleted,  the  system  also  checks  the  personnel  database 
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to  determine  if  someone  occupies  the  deleted  position.  If  a  matching  position  is  found 

in  the  personnel  database,  the  person's  TDA  position  information  is  blanked  in  their 

record,  and  the  following  message  is  displayed. 

FOUND  CPT  SMITH  OCCUPYING  THE  DELETED  POSITION! 
ID  CODE  IS  S2345  .  BE  SURE  VOU  UPDATE  THIS  PERSON'S 
TDA  POSITION  WITH  A  VALID  TDA  POSITION. 

(4)  Update   from   Resource   Information   Report.   This   menu   choice 

provides  the  user  with  the  capability  to  directly  update  the  personnel  database  with 

information  provided  in  the  Resource  Information  Report  personnel  sections.     Figure 

51  depicts  this  input  screen.  The  system  also  verifies  the  new  position  entered  to 

ensure  that  it  is  not  already  occupied,  and  if  it  is  occupied,  responds  with  the  screen 

of  choices  discussed  earlier. 


0PDATE  FROM  R.I.R.  REPORT 


B.  CHANGES  TO  CURRENT  TDA  (OTHER  THAN  LOSSES  OR  GAINS) 


OLD    POSITION 

NEW 

POSITION 

PAPA 

LINE 

POSN 

IDCODE 

LAST    NAME 

RANK 

PARA 

LINE 

POSN 

m 

jlJ 

■ 

■HS 

■SHHHMH 

Mi 

■i 

■ 

1 

PRESS  ESCAPE  [ESC]  TO  QUIT 

Figure  51.  Update  from  RIR  Report  screen. 

When  the  user  is  updating  from  the  personnel  losses  section  on 
the  RIR,  the  user  must  first  enter  the  PIC.  This  code  is  verified  in  the  manner 
discussed  earlier.  The  system  then  prompts  the  user  with.  "HAS  THTS  PERSON 
ACTUALLY  DEPARTED  OR  IS  THIS  AN  UPDATE  TO  A  PROJECTED  LOSS 
DATE?  (ACTUAL=0,  PROJECTED=  1 )  |."  If  the  change  is  a  modification  of  the 
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anticipated  loss  date,  the  user  enters  the  new  loss  date,  and  the  record  is  updated 
automatically.  If  the  loss  is  an  actual  PCS  from  the  department,  the  system  invokes  the 
same  procedures  as  described  for  the  deletion  of  personnel  in  Section  (2)  earlier. 

(5)  Enter,  change,  or  remove  CME  requests.  Figure  52  depicts  the 
standard  input  screen  for  the  CME  request.  This  screen  is  designed  to  match  the  format 
of  the  actual  printed  CME  request  form  used.  The  bottom  of  the  screen  is  used  to 
depict  whether  the  costs  displayed  are  actual  expended  costs  or  estimated  costs.  If  the 
user  desires  to  change  an  already  existing  record,  the  user  must  first  enter  the  fiscal 
year  of  the  request  and  the  PIC  code  of  the  person  sought.  As  discussed  earlier,  the 
confirmation  screen  displays  the  personnel  information  about  the  selected  PIC  with  the 
message,  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N)  |."  The  system  then 
displays  all  matching  records  in  the  following  format: 

RECORD  NO.      ID  CODE       TYPE      START  DATE       END  DATE 

5  S7777  C  06/07/89  07/07/89 

15  S7777  G  07/20/89  07/22/89 

ENTER  THE  RECORD  NUMBER  DESIRED  :  Hj 

The  user  is  then  prompted  with,  "WILL  COSTS  BE  ACTUAL  COSTS  OR 
ESTIMATED  COSTS?  (ENTER  AN  A  FOR  ACTUAL  OR  AN  E  FOR 
ESTIMATED):^."  The  system  takes  the  user's  response  and  enters  the  correct  cost 
code  into  the  record.  The  system  will  also  total  all  travel  costs  and  update  the  total 
cost  of  travel  field  in  the  record. 

In  the  case  where  the  user  only  wants  to  update  a  record  with  the 
actual  costs  and  selects  this  option  in  the  menu,  the  system  displays  the  same  screen 
in  Figure  52,  except  the  user  can  only  input  the  cost  portions  of  the  screen  format.  The 
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system  then  changes  the  cost  code  and  totals  the  costs  for  the  user  prior  to  updating 
the  record. 


SUBJECT:  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR  89 


1.  Type  of  Travel  Requested | 

C-Conference/Meeting  Travel   G-General  Mission  Travel  B-Board  Certification 


2.  ID  CODE  of  person  requesting  the  travel  is  S7396 
4.  Purpose  of  Travel  is 
6.  Destination 


5.  Registration  Fee   $1 


I.  Leave  Dates    Starting  Date 
Duration      0   days 


Mode  of  Travel  is  | 

F-FLY,  G-GOVT  VEH,  P-POV,  0-OTHER 

Ending  Date  ■  ■  ■ 


13.        TRAVEL    COST    ?|^jjg    |g  PER    DIEM    COST    $HB9 

TOTAL    COST    OF    TPAVEL    $  0.00 


REIMBURSABLES    $1 


EXPENSES    REFLECT    THE    ESTIMATED    COST    OF    TRAVEL 


Figure  52.  Continuing  Medical  Education  Request  Data  Entry  Screen 

Figure  53  depicts  the  input  screen  used  to  add,  change  or  remove 
the  records  in  the  CME  allocation  database.  There  is  only  one  CME  allocation  for  the 
department  for  each  fiscal  year.  Therefore,  the  user  is  always  required  to  enter  the 
fiscal  year  prior  to  using  this  screen  to  enter  the  CME  funds  allocation. 


UPDATE  CME  ALLOCATION 


THE  CME  ALLOCATION  FOR  FISCAL  YEAR  89  SHOULD  BE  $ 


Figure  53.  CME  Allocation  Data  Entry  Screen. 

(6)  Enter,  change,  or  remove  leave/absence  requests.  Figure  54  depicts 
tfec  data  entry  screen  for  the  absence  database.  Prior  to  using  this  screen,  the  user  must 
fisst  provide  the  fiscal  year  of  the  request  and  PIC  of  the  person  who  will  be  entered. 
Oaice  the  PIC  is  entered,  it  is  verified  against  the  personnel  database  and  if  it  is  found, 
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the   standard   confirmation   screen   is   displayed   with   the   message,    "IS   THIS   THE 
PERSON  YOU  EXPECTED?  (Y/N)". 


UPDATE  LEAVE  OR  ABSENCE  REQUEST 


This  is  the  Fiscal 

Year  89  Leave  or  Absence 

request  for  ID  CODE  S7396 

Type  of  Request 

• 

L.  . Regular  Leave 
P .. Permissive  TDY 

E. .Emergency  Leave 
C. .Convalescent  Leave 

T.. Other  TDY,  not  CME 
0. .Other 

Starting  Date   PB  H5  d     Ending  Date    |  fl|  I 
Duration    0  days 


COMMENT 

Figure  54.    Leave  and  Absence  Data  Entry  Screen 

If  the  user  is  changing  an  already  existing  record,  the  system  uses 
the  PIC  entered  to  display  the  following: 

RECORD  NO.       ID  CODE        TYPE       START  DATE        END  DATE 

5  S7777  C  06/07/89  07/07/89 

15  S7777  G  07/20/89  07/22/89 

ENTER  THE  RECORD  NUMBER  DESIRED  :  1 

Since  the  PIC  has  already  been  verified  with  the  confirmation  screen,  only  the  PIC 
number  is  displayed.  The  user  can  then  choose  the  record  desired.  As  discussed 
earlier,  the  ability  to  "point  and  shoot"  to  a  particular  record  would  enhance  the  user's 
ability  to  request  a  particular  record.  The  record  is  redisplayed  in  the  same  entry 
format  depicted  in  Figure  54. 

With  each  addition  or  change  of  a  record,  the  system  automatically 
recomputes  the  duration  field  by  subtracting  the  starting  date  from  the  ending  date.  This 
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constant  updating  insures  that  this  field  will  always  be  updated  prior  to  saving  the 
database. 

c.      Outputs 

(1)  Review  Screens.  The  review  of  the  personnel,  TDA,  absence,  and 
CME  request  databases  are  accomplished  by  the  use  of  the  standard  review  screen. 
Each  review  option  provides  the  user  with  the  generic  review  display  described  in 
Section  B  of  this  chapter.  The  data  fields  presented,  with  the  exception  of  the  CME 
request  database  and  the  absence  database,  are  simply  the  fields  existing  in  the 
database.  The  CME  request  database  and  absence  database  are  combined  with  the 
personnel  database  to  create  a  new  temporary  database  that  contains  the  name 
associated  with  each  PIC  in  the  databases.  The  additional  review  fields  displayed  with 
the  already  existing  fields  in  the  CME  request  or  absence  database  are  the  Rank,  First 
Name,  and  Last  name  of  the  person  that  matches  the  PIC  field  in  the  CME  or  absence 
databases. 

(2)  Position  Listing  (see  Figure  55).  This  report  provides  the  Chief 
with  a  listing  of  all  TDA  positions  within  his  department  and  the  personnel  assigned 
to  those  positions.  This  report  is  generated  by  combining  the  TDA  database  with  the 
personnel  database  where  the  TDA  position  in  the  personnel  database  matches  the  TDA 
position  in  the  TDA  database.  If  no  match  is  found,  the  TDA  information  is  printed 
but  with  the  personnel  information  left  blank.  If  the  person  is  carried  as  excess,  their 
information  is  also  printed  but  with  only  the  TDA  paragraph  number,  TDA  line 
number,  and  the  excess  position  code  of  99.  This  report  is  sorted  in  TDA  paragraph 
number,  line  number,  and  position  number  order  whether  the  position  is  filled  or  not. 
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DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNrTY  MEDICINE  (TDA) 

11   MAR  88 
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Figure  55.    Position  Listing  Rqport 

The  fields  necessary  to  create  this  report  are: 

•  Section  Description  for  each  TDA  Paragraph  Number. 

•  TDA  Paragraph  Number. 

•  TDA  Line  Number. 
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TDA  Position  Number. 

Authorized  Grade  for  above  TDA  position. 

Authorized  MOS  for  the  above  TDA  position. 

Authorized  Branch  for  the  above  TDA  position. 

TDA  Official  Job  Title. 

Rank. 

Last  Name. 

Authorization  Code  for  the  position. 

Doctor  Status  Code.  This  code  reflects  the  current  residency  status  of  a  doctor 
in  the  residency  program. 

Anticipated  date  of  PCS  for  the  person  in  the  position. 

The  following  numbered  items  correspond  with  the  numbers  in 

Figure  55. 

1  This  section  title  correlates  to  the  TDA  paragraph  number  in  the  TDA. 

2  This  subtotal  is  the  total  authorized  positions  within  the  TDA  Paragraph 
number.  This  is  calculated  by  totaling  the  authorized  position  fields  for  each 
paragraph  number. 

3  This  is  the  number  of  persons  assigned  to  a  particular  TDA  paragraph.  This 
number  is  calculated  by  counting  the  number  of  TDA  positions  where  the  name 
field  is  not  blank  within  the  same  TDA  paragraph  number. 

4  If  no  name  is  associated  with  a  TDA  position,  the  phrase  "VACANT"  is 
printed  in  this  field. 

5  The  doctor  status  codes  in  the  database.  They  are  also  explained  in  a  footnote 
at  the  bottom  of  the  report. 

6  The  RANK,  FIRST  NAME  and  LAST  NAME  of  the  person  who  occupies  a 
TDA  position  are  concatenated  to  produce  this  field. 
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7  This  total  is  the  total  for  the  department  and  is  a  total  of  all  the  TDA 
paragraphs  suhtotals. 

8  Personnel  whose  position  code  is  designated  as  99  do  not  have  a  job  title  since 
they  are  carried  in  an  excess  capacity. 

9  This  "•"  flag  indicates  that  the  person  listed  has  an  anticipated  loss  date  that 
is  less  than  60  days  from  the  current  system  date. 

(3)  Section  Update  Worksheet  (see  Figure  56).  This  worksheet  allows 

the  department  to  update  its  personnel  database  with  new  position  information,  changes 

or  additions  to  the  anticipated  loss  date  field,  and  changes  to  the  personnel  status  field. 

This  report  is  very  similar  to  the  position  listing  with  the  exception  of  the  following: 

•  Each  paragraph  within  the  TDA  is  printed  separately  to  facilitate  individual 
delivery  to  sections. 

•  There  are  three  fill  in  the  blank  fields  added  to  allow  the  section  to  directly 
annotate  changes  into  the  worksheet. 

This  report  is  created  from  the  same  combination  of  databases 

necessary  for  the  personnel  listing,  but  only  the  following  fields  are  needed  to  print 

this  worksheet: 

Section  Description  for  each  TDA  Paragraph  Number. 

TDA  Paragraph  Number. 

TDA  Line  Number. 

TDA  Position  Number. 

TDA  Official  Job  Title. 

Rank. 

Last  Name. 
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•  Doctor  Status  Code  for  the  person  who  occupies  the  TDA  position.  (Only 
applies  to  doctors  in  the  residency  program). 

•  Anticipated  date  of  PCS  for  the  person  in  the  position. 


SECTION  WORKSHEET 
DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

11  MAR  88 


PARA     LINE 


POSN     JOB  TITLE      RANK/NAME    STATUS      ALOSS      NAME 


FAMILY  PRACTICE  CLINIC  (FPC) 


S32 


532 


532 
532 
532 


532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
632 


532 
532 
532 
532 
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532 
532 
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01 

02 

02 

02A 

02A 
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03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

04 

05 

06A 

06 

07 

08 

09 

00 

10 

10 

10 

12 

12 

12 

68 

88 

88 

68 

88 

88 

88 

88 


PARAGRAPH 


01 
01 
02 
01 
02 
03 
90 
01 
02 
03 
04 
05 
08 
07 
08 
09 
10 
11 
12 
13 
14 
01 
01 
01 
01 
01 
01 
01 
02 
01 
02 
99 
01 
02 
03 
01 
02 
03 
04 
05 
08 
07 
06 

TOTAL 


FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 

FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
HEAD  NURSE 
MED  SURG  NUR 
AOMIN  SUPV 
CUNIC  NCO 
MED  SP 
MED  SP 
MED  SP 
MED  SP 
MED  SP 
MED  SP 

MED  CLK  (T) 
MED  CLK  (T) 
MED  CLK  (T) 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 
FAM  PHYS 


AUTHORIZED  :  26      ASSIGNED  :  37 


07/2O/79 
99/99/99 
99/99/99 
90/99/99 

07/20/70 


8858PB5**' 


06/10/90 


06/29/91 


3w(fefSJSK)i»w#««s*^<'-*^^*-.-  - 


(1)  -  M  YEAP  RESOEHCY  (2)  .  2nd  YEAH  RESIDENCY  (J)  .  1ST  YEAR  HBStOEHCY  tSTUOENT) 


Figure  56.  Section  Update  Worksheet 

The  following  numbered  items  correspond  with  Figure  56. 

1  These  fields  are  intentionally  left  blank  to  allow  the  section  to  input  changes 
to  the  current  TDA  position  listing. 

2  The  RANK  and  LAST  NAME  of  the  person  who  occupies  a  TDA  position 
are  concatenated  to  produce  this  field. 
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(4)  Loss  Report  (see  Figure  57).  This  report  provides  the  department 
with  a  listing  of  all  personnel  who  have  an  anticipated  PCS  date  between  two  user 
specified  dates.  Prior  to  printing  this  report,  the  user  is  required  to  enter  these  dates 
to  define  the  parameters  for  which  this  report  will  be  printed. 

LOSS  REPORT 
DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 


11  MAR  89 


START  DATE  :    06/01/89 ^—  ENDING  DATE  :  09/25/89 

The  following  personnel  have  expected  anticipated  loss  dates  within  the 
above  dates: 

RANK  NAME  SECTION   PCS  DATE 


CPT 

JOHN  SMITH 

AMB 

07/01/89 

CPT 

JANE  DOE 

CTM 

09/01/89 

MSG 

GERY JONES 

CTM 

07/09/89 

1LT 

WAYNE  SHARPE 

FPC 

07/20/89 

Figure  57.    Loss  Report 

This  following  fields  are  necessary  to  print  this  report. 

•  Rank. 

•  Last  Name. 

•  Section  Description  for  the  person. 

•  Anticipated  Date  of  Loss. 

The  following  numbered  items  correspond  with  Figure  57. 

1  The  date  parameters  for  the  report  entered  by  the  user. 

2  The  date  in  this  field  must  lie  between  the  parameter  dates  established  by  the 
user. 
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(5)  Vacancy  Listing  (see  Figure  58).  This  report  provides  a  listing 
of  all  TDA  positions  within  the  department  that  are  vacant.  This  report  provides  the 
Chief  with  a  quick  look  at  his  personnel  shortages  and  the  current  vacant  positions 
within  the  department. 

VACANCY  REPORT 
DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

11  MAR  89 

The  following  TDA  Positions  are  vacant: 


PARA  LINE  POSN  GR       MPS    BR 

FAMILY  PRACTICE  CLINIC  (FPC) 

532  03  13  03  61H00      MC 

532  03  14  03  61H00      MC 

532  12  02  03  00679       GS 


JOB  TITLE 


AUTH 


FAM  PHYS  (J^C>.    NO 

FAM  PHYS  \^NO 

MED  CLK  (T)  XYES 


®^l 


PARAGRAPH  SUBTOTAL  ***  VACANCIES  :  3—® 
EMERGENCY  MEDICAL  SERVICE  (EMS) 

581  17  01  13  00602       GS  GEN  MED  OFF 

581  17  02  13  00602       GS  GEN  MED  OFF 


PARAGRAPH  SUBTOTAL  ***    VACANCIES  :  2  - 


-® 


YES 
YES 


BOTAL  DEPARTMENT  VACANCIES  :  5 
Figure  58.  Vacancy  Listing 

This  report  file  is  generated  in  the  same  manner  as  the  position 
listing  except  that  only  the  TDA  positions  which  do  not  have  a  matching  person 
assigned  to  a  position  are  printed. 

The  following  numbered  items  correspond  with  Figure  58. 

1  This  is  a  count  of  all  authorized  positions  that  are  vacant  within  a  given  TDA 
paragraph  number.  This  total  represents  the  sum  of  the  authorized  field  for  the 
TDA  paragraph. 
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2  If  the  position  is  authorized  (code=l),  "YES"  is  displayed,  otherwise  "NO"  is 
displayed. 

3  Total  Department  Vacancies.  This  total  is  the  sum  of  all  TDA  paragraph 
subtotals  mentioned  in  Note  1  above. 

(6)  Social  Roster  (see  Figure  59).     This  roster  provides  personnel 

within  the  department  a  roster  of  personal  information  of  assigned  personnel  within  the 

department.  This  roster  both  serves  as  a  social  listing  to  facilitate  social  gatherings  and 

as  an  emergency  notification  listing  for  department  personnel.  The  creation  of  this 

report  requires  the  combination  of  the  personnel  database  and  personal  database.  In  the 

case  where  there  is  not  a  match  to  a  personnel  record  in  the  personnel  database,  "NO 

PERSONAL  DATA"  is  printed  in  the  report. 

The  fields  necessary  to  create  this  report  are: 

Last  Name. 

First  Name  and  Middle  Initial. 

Rank. 

Branch  of  Service. 

Military  Occupational  Specialty  Code. 

Arrival  Date  within  the  Department. 

TDA  Official  Job  Title. 

Section  Description  for  each  TDA  Paragraph  Number. 

Local  Home  address. 

City  of  Home  address. 

State. 

Spouse's  first  name. 
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•  Children's  names,  followed  by  their  ages  (if  appropriate). 

•  Home  telephone  number. 

•  Date  of  rank. 


SOCIAL  ROSTER 
DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

11  MAR  89 


PRIVACY  ACT  STATEMENT 
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W&M 
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DEPARTMENT  OF  FAMILY  PRACTICE  (PEP) 

LTC        SMITH,  JOHN  R.  POSN:  C,  DEPT  FP 

BR:  MC  MOS:  61H00      ARR:  07/20/87 

1200  BIRDTREE  LANE 

ANYWHERE  STATE  99999-9999 

PHONE:  (408)999-9999 

WIFE:  BECKY  CHILDREN:  JIM/10,  MIKE/4,  SUE/1 

FAMILY  PRACTICE  CLINIC  (FPC) 

LTC       JONES,  SUE  R.  POSN:  FAM  PHYS 

BR:  MC  MOS:  61H00     ARR:  07/20/88 

1200  SINGASONG  ROAD 

ANOTHERPLACE  STATE  99999-9999 

PHONE:  (408)888-8888 

WIFE:  N/A         CHILDREN:  BECKY  JOE/1 

MAJ       BURB,  HERB  R.  POSN:  FAM  PHYS 

BR:  MC  MOS:61H00     ARR:  06/11/85 

23  CHIRPING  TREE  LANE 

ANYWHEREELSE  STATE  99999-9999 

PHONE:  (408)444-4444 

WIFE:  JO  CHILDREN: 


Figure  59.    Social  Roster 
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This  report  is  created  in  the  format  shown  in  Figure  59.  Entries 
are  sorted  by  TDA  paragraph  number  and  then  by  rank  within  the  position  paragraph 
number. 

(7)  Monthly  Absence  Report  (see  Figure  60).  This  report  provides  the 
department  with  a  listing  of  personnel  who  have  planned  absences,  either  a  planned 
CME  course  or  a  regular  absences  (i.e.,  leave),  within  an  selected  month.  This  report 
is  used  by  the  department  managers  and  the  clinical  director  (see  scheduling 
information  system)  to  manage  personnel  assets  on  a  month  to  month  basis.  The  user 
is  required  to  enter  the  month  and  the  fiscal  year  desired  prior  to  output  of  this  report. 
This  report  is  generated  by  combining  the  absence  database  and  the  CME  request 
database  and  then  combining  this  new  database  with  the  personnel  database  to  get  the 
rank  and  name  of  the  person  who  plans  to  be  absent  in  the  selected  month.  The  report 
file  is  then  sorted  by  section  and  last  name  prior  to  printing. 


MONTHLY  ABSENCE  REPORT 
DEPARTMENT  OF  FAMILY  PRACTICE  &  COMMUNITY  MEDICINE 

1 1   MAR  89 


MONTH  :    JULY 


1 


FISCAL  YEAR  :  89 


The  following  personnel  have  planned  absences  during  the  month  of  July 


RANK  NAME 


® 


abgenq 


"N 


SECTION    START  DATE  END  DATE   TYPE 


CPT 

JOHN  SMITH *-* 

JANE  DOE           Cn<        + 
GERY  JONES     W 

AMB 

07/01/89 

07/1 5^89 

CME 

CPT 
MSG 

CTM 
CTM 

06/01/89 
07/09/89 

07/02/89      s~ 
08/25^89      M 

>_^  EMER  LV 
LT      LEAVE 

1LT 

WAYNE  SHARPE 

FPC 

07/20/89 

07/22/89 

\    PERMTDY 

SGT 

WAYNE  ROGERS 

POM 

07/30/89 

08/30/89 

ORD  TDY 

Figure  60.  Monthly  Absence  Report. 
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The  fields  required  to  produce  this  report  are: 
Rank  of  the  person  who  has  an  absence  planned  during  the  requested  month. 
Last  Name. 
First  Name. 
Section  of  assignment. 
Start  date  of  planned  absence. 
End  Date  of  planned  absence. 
Type  of  Absence. 

The  following  numbered  items  correspond  with  Figure  60. 

1  The  fiscal  year  and  month  desired  are  entered  by  the  user  prior  to  output  of 
report.  If  the  record  in  the  combined  database  falls  within  the  requested  start  date 
or  end  date,  the  absence  record  is  included  within  the  report.  If  the  record  is 
inclusive  of  the  requested  start  and  end  date,  e.g.,  a  request  in  July  falls  between 
a  user  specified  start  date  in  June  and  an  end  date  August,  the  record  will  be 
included  in  the  report. 

2  Section  codes  are  sorted  to  keep  personnel  along  organizational  lines.  The 
secondary  sort  is  on  the  last  name. 

3  Type  request  code  is  converted  to  its  full  text  format.  Care  must  be  taken  not 
to  assign  the  same  type  code  to  both  the  CME  database  and  the  absence  database. 

4  The  RANK,  FIRST  NAME,  and  LAST  NAME  fields  are  concatenated  to  give 
the  appearance  that  the  field  is  one  field. 

(8)  Fiscal  Year  Summary  of  Physician  Absences  (see  Figure  61).   This 

summary  report  provides  the  Department  Chief  with  the  ability  to  monitor  and  evaluate 

the  number  of  and  frequency  of  doctor  absences  within  the  department.  This  report 

serves   as  an  indicator  of  doctor  availability  over  the  fiscal  year  and  shows  the 

frequency  of  absences  by  type  of  request.  This  report  is  generated  in  the  same  manner 

as  described  in  the  absence  report  except  this  report  is  not  restricted  to  one  month  and 
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extracts  only  doctor  information.  The  user  is  only  required  to  enter  the  fiscal  year 
desired.  The  fields  necessary  to  generate  this  report  are  the  same  as  the  absence  report 
but  also  include  the  duration  field  from  both  of  the  databases. 


FISCAL  YEAR  ABSENCE  SUMMARY 

DEPARTMENT  OF  FAMILY  PRACTICE  & 

COMMUNITY  MEDICINE 

11  MAR  89 


FISCAL  YEAR  :  89 


NAME 


LTC  JOHN  SMUCK 


START  DATE 


TYPE 


TYPE 


0 


CME  REQUEST 

01/01/89 

06/05/89 

Subtotal 

ORDINARY  LEAVE 

03/05/89 

06/10/89 
Subtotal 


Total. 


END  DATE 


01/30/89 
06/10/89 


DURATION 


03/30/89 
06/20/89 


LTC  JANE  SMITH 

TYPE    :     CME  REQUEST 

03/01/89  03/30/89 

04/01/89  04/19/89 

05/05/89  05/15/89 

Subtotal 

—TYPE    :     PERMISSIVE  TDY 

09/25/89  09/30/89 

Subtotal 

'—TYPE    :    ORDINARY  LEAVE 

02/01/89                      02/28/89 
Subtotal 


29 
_5 

34 


\ 


w 

6*9  days 


29 
18 
1Q 
57 

_5 
5 

iZ 
27 


Total. 


§9  days 


Figure  61.  Fiscal  Year  Summary  of  Physician  Absences. 
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The  following  numbered  items  correspond  with  Figure  61. 

_1  Each  person  identified  as  having  at  least  one  absence  during  the  fiscal  year  is 
reported  in  last  name  order. 

2  Under  each  person,  all  absences  are  sorted  by  request  type  in  alphabetical  order 
with  breaks  between  different  types  of  absences. 

3  Duration  is  extracted  directly  from  the  databases  reflecting  the  End  Date  minus 
the  Start  Date  in  days. 

4  Subtotal  of  the  duration  for  each  type  of  absence,  for  each  person. 

5  Total  duration  for  all  absences  for  the  given  person. 

(9)  CME  Reports  (Actual  and  Estimated)  (see  Figures  62  and  63). 
These  reports  allow  the  Department  Chief  to  monitor  the  CME  expenditures  and 
estimate  the  funds  remaining  for  a  given  fiscal  year.  The  CME  reports  are  critical  in 
keeping  track  of  the  limited  funds  available  to  send  doctors  to  the  training  necessary 
to  keep  them  certified  in  critical  medical  skills. 

These  two  reports  are  very  similar  but  are  used  in  separate  contexts. 
The  Actual  CME  Budget  Expenditure  Report  is  used  to  report  the  amount  actually 
spent  during  a  given  fiscal  year,  excluding  all  estimated  costs  figures.  This  report  gives 
the  Department  Chief  an  accurate  look  at  the  funds  remaining  for  the  requested  fiscal 
year.  The  Estimated  CME  Budget  Expenditure  report  not  only  gives  the  Chief  a  look 
at  what  funds  have  actually  been  spent,  but  also  provides  a  listing  of  the  approved 
CME  funded  travel  for  which  travel  claims  have  not  yet  been  settled.  This  report  is 
also  used  at  the  beginning  of  the  fiscal  year  to  report  the  projected  expenditures  for 
a  requested  fiscal  year. 
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CONTINUING  MEDICAL  EDUCATION 
ACTUAL  FUNDS  REPORT 


DEPARTMENT  OF  FAMILY  PRACTICE  I 
COMMUNITY  MEDICINE  (TDA) 


11    DEC    89 

r 

NAME 

RAN? 

DATES    OF 

TDY 

LOCATION 
OF    TOY 

REASON 
FOR   TDY 

TRAVEL 
COST 

PER            REG       REIMB       TOTAL 
DIEM            FEE         COST         COST 

\ UNCOMMITTED 
\                  FUNDS 

JOHN 
JANE 

CPT 
MAJ 

09/09/89- 
10/10/89- 

-09/20/89 
-11/20/89 

LAS    VEGAS, 
RENO,     NV 

NV 

ORTHO 
AOA 

147.00 
169.25 

FUNDS   ALLOCATED    : 

320.00    395.00                 0    862.00 
437.50    210.00              50    866.75 

^-♦•16789.92 

SMITH, 
JONES, 

,♦15927.92 
1     15061.17 

(3k 


®/i 


CME  TRAVEL  APPROVED  BUT  NOT  COMPLETED  (ESTIMATED  COSTS) 
PROJECTED  FUNDS  REMAINING 

Figure  62.    Actual  CME  Budget  Expenditure  Report 


CONTINUING 

MEDICAL 

EDUCATION 

ESTIMATED 

FUNDS 

REPORT 

DEPARTMENT 

OF 

FAMILY    PRACTICE    4 

COMMON! 

TY 

MEDICINE 

(TDA) 

RANK    DATES    OF    TDY 


LOCATION 
OF    TDY 


REASON         TRAVEL  PER  REG      REIMB       TOTALX      UNCOMMITTED 

FOR   TDY  COST         DIEM  FEE         COST         COST     \  FUNDS 


FUNDS    ALLOCATED 


SMITH,    JOHN  CPT      01/05/89-01/20/89        LAS   VEGAS,    NV        ORTHO  147.00    320.00    395.00  0   862.00  r»15927. 92 

JONES,    JANE  MAJ      05/10/89-05/20/89        RENO,    NV  AOA  169.25    437.50   210.00  50   866.75         /       15061.17 

ANDERS,     KEN  CTT       07/20/89-08/15/89  SAN    DIEGO,     CA         EMERG  100.00    400.00    200.00  50    750.00        /         14311.17 


ALL    ESTIMATED    AND    ACTUAL    TRAVEL    COSTS    REPORTED    HERE 


® 


PROJECTED    FUNDS    REMAINING 


Figure  63.    Estimated  CME  Budget  Expenditures  Report 

The  user  is  required  to  enter  the  fiscal  year  of  the  report  prior  to 
creation  of  either  report.  The  fields  required  to  create  these  reports  are: 

•  Last  Name  of  requestor. 

•  First  Name. 

•  Rank  of  the  requestor. 

•  Start  and  End  dates  of  travel. 

•  Destination. 
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•  Puipose  of  Request,  e.g.,  ORTHO  WORKSHOP. 

•  All  Costs  of  travel,  including  the  Travel  Cost,  Per  diem  costs,  registration  fee, 
reimbursable  expenses,  and  total  cost  fields  of  the  request. 

•  Cost  Code,  whether  it  is  an  actual  accrued  cost  or  an  estimated  cost  of  the 
travel. 

•  Allocated  CME  budget  for  the  fiscal  year  from  the  CME  allocation  database. 

To  create  this  report  requires  that  the  CME  request  database  be 
combined  with  the  personnel  database  to  match  the  name  of  a  person  with  the  PIC  in 
the  CME  request  database.  The  CME  allocation  database  is  also  used  to  determine  the 
actual  allocation  for  the  selected  fiscal  year. 

The  following  numbered  items  correspond  with  the  numbers  in 
Figures  62  and  63. 

1  This  number  is  the  actual  allocation  for  the  current  fiscal  year  selected. 

2  This  is  an  accumulated  total  of  the  actual  costs  incurred  for  the  current  fiscal 
year. 

3  This  number  reflects  the  allocation  for  the  current  fiscal  year  minus  the  actual 
expenses  already  incurred. 

4  This  figure  is  the  previous  allocation  minus  the  total  cost  of  travel  for  the 
current  record. 

4.      Scheduling  Information  System 

We  concluded  in  Chapter  IV  that  although  automating  the  scheduling  system 
would  be  impractical,  improvements  could  be  made  in  the  system  by  standardizing  the 
forms  used  in  data  collection  and  reporting. 

Figure  64  is  the  UCD  depicting  the  proposed  scheduling  system.  Although 
most  of  the  scheduling  process  will  remain  the  same,  the  clinical  director  will  now  be 
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able  to  get  pre-printed  standard  forms  for  recording  doctor  availability  information. 
These  forms  can  be  created  with  commercially  available  software  packages  (e.g., 
FORMTOOL)  and  maintained  on  diskettes  in  the  administration  office. 


Doctor  Monthly 
Schedule 


Department 

Appointment 

System 

(COSTARS) 


Create 

Doctor 

Schedules 


Doctor 
Availability 
Information 


Clinical  Director 


Scheduling 
Folder 


Record 

Doctor 

lnformat:on 


Doctor  Information 


Blank  Forms 


Print 

Schedule 

Forms 


File  Forms 


Form 
Selections 


a 


Mij 


K 


m 


Form 
Changes 


Forms  File 


Update 

Schedule 

Forms 


Form 
Updates 


Figure  64.    Scheduling  User  Concept  Diagram 
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After  discussions  with  the  clinical  director,  it  was  determined  that  the  most 
valuable  forms  to  standardize  are  the  duty  history  sheet,  the  monthly  cumulative  tally 
sheet,  and  the  clinic  schedule  template.  Other  sources  of  information  such  as  the  3x5 
cards  containing  staff  doctor  and  resident's  special  availability  instructions  were 
considered  to  be  adequate  in  their  current  form.  The  resulting  forms  are  shown  in 
Figures  65  and  66. 

Figure  65  is  the  Duty  History  Record  which  is  a  combination  of  the  duty 
history  sheet  and  the  monthly  cumulative  tally  sheet.  A  completed  duty  history  record 
will  provide  the  scheduler  with  a  comprehensive  history  of  each  doctor's  on  call  duty. 

Figure  66  is  the  clinic  schedule  template.  Since  this  form  is  a  template, 
the  staff  doctors  permanent  schedules  are  included.  The  template  can  be  penciled  in 
by  the  scheduler  to  show  residents'  schedules  for  the  month.  The  resident's  names  can 
then  be  entered  into  the  form  using  the  fill-in-form  option  of  FORMTOOL  and  a 
complete  schedule  can  be  printed  for  distribution.  The  clinical  director  liked  the  idea 
of  the  template.  The  template  can  be  changed  easily  and  each  month  a  clean  template 
can  be  used  without  having  to  first  delete  the  resident's  names  from  the  previous 
month's  schedule. 


Dole 


Duty  History  Record 


Doctor  Nome     Jon  Feb  Mar  Apr   May  Jun  Jul   Aug  Sep  Oc!   Nov  Dec  /Weekends  /Holidays     Holidays 


Figure  65.      Duty  History  Record 
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M->nth      Yr 

Schedule  Template 

TEAMS 

MONDAY 

TUESDAY 

WEDNESDAY 

THURSDAY 

FRIDAY 

Gold    A 
M 

Lorenzen 

Mork 

Foster 

Birdsong 

Landauer 

Crisp 

Foster 

Lorenzen 
Foster 

Spinelli 
Herman      P 
Terrio,  H   M 

Mork 

Foster 

Lorenzen 
Mork 

Foster 

Mork 

Mork 
Foster 

Red     A 
M 
Forred 
Hutnak 
Lee 

Schmidt 
Walcott 
Bradley 

Forred 

Forred 
Fuller 

Fuller 

Forred 

Sorensen 

P 
M 

Fuller 

Forred 

Forred 
Fuller 

Fuller 

Blue    A 
M 
Kugler 
Spaulding 
Yeash 
Ard 
Runkle 
Davis 
Goodrich 

Spaulding 
Kugler 

Spaulding 
Yeash 

Kugler 
Yeash 

Spaulding 

Fitzharris 

Yeash 

Spaulding 
Kugler 

Swann 

Terrio, J    P 
Weaver      M 

Yeash 

Fitzharris 
Kugler 

Spaulding 

Kugler 

Yeash 

Figure  66.  Schedule  Template 
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5.      Patient  Satisfaction  Information  System  (see  Program,  Appendix  F) 
a.      Data  Structures 

As  can  be  seen  in  the  UCD  in  Figure  67,  the  entire  patient  satisfaction 
system  hinges  on  completed  patient  surveys,  the  results  of  which  are  entered  into  a 
survey  database  for  use  in  report  generation. 


Blank  Survey 


Survey 


Complete 
Survey 


Completed  Survey 


Doctor 


Patient 


/I 


f^^ 


Report 
Select 


g  BUUj 

r 


QA   Rep,    Clerk 


2.0    Print 
Reports 


R*  ports 


Reception 
Deek 
Box 


New  Survey 
Data 


Survmy 
Data 


Clinic 

Reports 


1.0   Enter   New 

Survey 

Data 


Dept. 
Reports 


7 


Input  Data 


A— A 


till, 


h 


1 


Cllnlce 


QA  Rep.   Clerk 


Chief 

Figure  67.    Patient  Satisfaction  User  Concept  Diagram 

The    approved    opinion    survey,    designed    in    cooperation    with    the 
Department  Chief  and  the  Quality  Assurance  (QA)  representative,  is  shown  in  Figure 
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68.  The  questions  and  answers  cover  those  areas  of  most  concern  to  the  Department 
Chief.  The  survey  form  determines  the  data  structure  of  the  database  itself,  with  data 
fields  corresponding  to  each  question.  The  following  data  fields  are  used  in  the 
database  to  record  survey  data. 

Month.  The  month  the  survey  was  completed  by  the  patient. 

Year.  Calendar  year  the  survey  was  taken. 

Section  Code.  Same  as  systems  above. 

Doctor's  Name.  The  name  of  the  doctor  seen  by  the  patient  completing  the 
survey. 

Appointment  Days.  Question  1A. 

Appointment  Acceptability.  Question  IB. 

Records  Ready.  Question  2. 

Waiting  Time.  Question  3A. 

Waiting  Acceptability.  Question  3B. 

Receptionist  Courtesy.  Question  4. 

Nursing  Courtesy.  Question  5. 

Doctor  Courtesy.  Question  6 

Procedures  Explanations.  Question  7. 

Time  Spent  With  Doctor.  Question  8. 

Clinic  Cleanliness.  Question  9. 

Overall  Satisfaction.  Question  10. 

Patient  Comments  to  Enter?.  The  user  entering  the  survey  results  into  the 
survey  database  must  enter  a  "Y"  in  this  field  to  indicate  there  are  comments 
to  be  added  to  the  database  for  this  survey.  An  "N"  indicates  there  are  no 
comments.    The  following  section  on  Inputs  explains  this  further. 
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Comments.  A  memo  field  which  the  user  can  fill  from  comments  made  on  the 
patient  surveys. 


Department  of  Family  Practice 
Fatient  Opinion  Survey 

Your  opinion  is  important  to  us.  Please  complete  this  survey  and  return  it 
to  the  box  located  at  the  reception  desk. 

Sincerely, 

Chief,  Department  of  Family  Practice 


Month 


Year 


Clinic 


Doctor 


PLEASE  CIRCLE  THE  ANSWER  TO  THE  RIGHT  OF  EACH  QUESTION 


l.A.How  many  days  did  it 
take  to  get  your 
appointment? 


B.Was  this  time 
acceptable? 


2. Were  your  records  ready 
at  the  front  desk? 


3. A. How  long  did  you  wait 
to  see  the  doctor? 


B.Was  the  waiting  time 
acceptable? 


1)  Same    2)  Less    3)  Less 
Day     than  7     than  14 


4)  Less 
than  30 


5)  More 
than  30 


1)  Acceptable 


2)  Not  Acceptable 


YES 


2)  NO 


1)  Less  2)  Less  3)  Less  4)  Less  5)  More 
than  than  than  than  than 
15  min     30  min     45  min     1  hour     1  hour 


1)  Acceptable 


2)  Not  Acceptable 


PLEASE  CIRCLE  THE  NUMBER  TO  THE  RIGHT  OF  EACH  QUESTION  WHICH  MOST  CLOSELY 
MATCHES  YOUR  OPINION  BASED  ON  THE  FOLLOWING  SCALE: 

5=Excellent    4=Good    3*=OK    2=Needs  Improvement    l=Unsat isf actory 


4.  Courtesy  of  receptionists 

5.  Courtesy  of  nursing  staff 

6.  Courtesy  of  doctor 

7.  Explanation  of  procedures  (lab  work,  EKG's,  etc) 

8.  The  amount  of  time  the  doctor  spent  with  you.... 

9.  The  general  cleanliness  of  the  clinic 

10.  Overall  satisfaction  with  the  care  you  received. 


5  4  3  2  1 

5  4  3  2  1 

5  4  3  2  1 

5  4  3  2  1 

5  4  3  2  1 

5  4  3  2  1 

5  4  3  2  1 
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THANK  YOU  ! ! 


Figure  68.    Opinion  Survey  Form 
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b.      Data  Inputs 

The  Patient  Opinion  menu  hierarchy  chart  is  depicted  in  Figure  69. 
The  user  can  enter  new  survey  data  using  the  input  screen  shown  in  Figure  70.  This 
input  screen  contains  all  of  the  data  base  fields  arranged  in  a  format  similar  to  the 
actual  survey  for  simplified  data  entry.  The  answers  to  the  survey's  numbered 
questions  are  coded:  the  user  simply  enters  one  number  corresponding  to  the  survey 
answer.  Since  each  question  has  a  predetermined  number  of  responses,  error  checking 
is  simply  a  matter  of  verifying  the  input  number  falls  in  the  allowable  range.  For 
example,  question  1A  has  five  possible  answers.  If  the  user  entered  anything  other 
than  one  through  five,  a  bell  would  sound  and  a  message  saying  the  input  was  out  of 
range  would  appear  at  the  bottom  of  the  screen.  The  user  is  then  given  the  chance  to 
enter  the  correct  answer.  At  the  bottom  of  the  input  screen  the  user  is  asked  if  there 
are  comments  to  be  entered.  The  user  enters  a  "Y"  or  "N"  in  the  Patient  Comments 
to  Enter  field.  The  Patient  Comments  to  Enter  field  is  necessary  when  printing  the 
patient  comments  report  discussed  in  Outputs  below  because  a  memo  field  in  the 
database  program  cannot  be  used  to  determine  records  to  print.  Therefore,  it  is 
necessary  to  have  a  second  field  whose  value  indicates  whether  the  comment  field  is 
filled  to  allow  only  those  records  with  comments  to  be  printed. 

The  use  of  mark-sense  forms  would  allow  automatic  entry  of  the  survey 
data  into  the  database.  Unfortunately,  neither  the  department  nor  the  hospital  has  the 
computer  hardware  to  read  mark-sense  forms  and  there  are  no  plans  to  acquire  such 
technology.  Additionally,  we  feel  the  added  complexity  of  mark-sense  forms,  e.g., 
special  marking  requirements  and  additional  instructions,  would  deter  some  patients 
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from  completing  the  surveys.     Also,  the  requirement  to  purchase  specially  designed 
forms  may  deter  the  department  from  obtaining  the  surveys. 

PATIENT  OPINION  SYSTEM 


MAIN 
MENU 

ENTER 
NEW  SUKVCY  DATA 

PRINT 
OPINION  RESULTS 

ACCESS 
TO  CARE  REPORTS 

WATTING 
TIME  REPORTS 

SATISFACTION 
REPORTS 

OOCTOR 
REPORT 

PATIENT 
COMMENTS 

OEPAf 
REPOI 

CLINIC 
_ REPOI 

tTVCNT 

n 

DEPARTMENT 
REPORT 

CLINIC 
_  REPORT 

DEPARTMENT 
REPORT 

CLINIC 
_  REPORT 

Figure  69.    Patient  Satisfaction  Menu  Hierarchy  Chart 
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Figure  70.    Patient  Satisfaction  Input  Screen 
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Once  the  survey  data  is  entered  into  the  database,  the  user  can  print 
one  of  several  reports.  After  selecting  the  report  desired  from  the  menu,  the  user  is 
prompted  to  enter  information  which  further  identifies  the  report  parameters  such  as 
year,  month,  and  (if  necessary)  the  clinic's  section  code.  This  information  is  used  to 
gather  the  data  necessary  to  create  the  desired  output. 
c.      Outputs 

(1)  Access  to  Care  Reports  (see  Figure  71).  There  are  two  access  to 
care  reports,  one  for  the  department  as  a  whole,  and  one  for  each  clinic.  Both  consist 
of  two  parts  and  are  identical  in  content  and  appearance.  However,  for  clinic  reports, 
only  the  survey  data  for  the  selected  clinic  is  used.  Part  One  of  the  report, 
Acceptability  of  Appointment  Access  indicates  to  the  Department  Chief  the  patients' 
opinions  on  the  acceptability  of  the  length  of  time  it  took  them  to  obtain  an 
appointment.  Part  Two,  Average  Days  to  Get  Appointment,  allows  the  Department 
Chief  to  examine  the  trend  in  the  average  number  of  days  to  get  an  appointment. 

The  following  fields  are  necessary  for  creating  the  two  part  access 
to  care  reports. 

Month. 

Year. 

Section  Code.  For  clinic  report  only. 

Appointment  Days. 

Appointment    Acceptability.    Required    only    for    Part    1,    Acceptability    of 
Appointment  Access. 
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Acceptability  of  Appointment  Access 


Number  of  Responses 


Same  day 


<  7 


<   14 


<  30 


>   30 


2 

Acceptable 


Days  to  Get  Appointment 

(4) 


Not  Acceptable  *     Total  Responses 

Average  Days  to  Get  Appointment 


>  30 
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Same 
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MAR 
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1989 
Average  Days 


MAY 
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Figure  71.  Access  to  Care  Report 
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The  following  numbered  items  correspond  to  the  numbers  shown 

in  Figure  71  and  explain  the  data  manipulations  and  calculations  required  to  produce 

the  report. 

1.  The  total  number  of  responses  for  each  possible  answer  to  survey  question  1A 
are  graphed  along  the  Y-axis  based  on  note  2  below. 

2  For  each  possible  answer  to  question  1A,  the  number  of  patients  who 
responded  to  question  IB  as  acceptable  and  unacceptable  are  counted  and  each 
count  is  graphed  as  a  separate  bar.  For  example,  in  the  figure,  for  those  patients 
that  said  it  took  them  less  than  seven  days  to  get  an  appointment,  15  said  this 
was  acceptable  and  one  said  this  was  unacceptable. 

3  The  total  response  line  shows  the  total  responses  for  each  possible  answer  to 
question  1A,  appointment  days. 

4  This  is  the  month  and  year  of  the  survey.  This  data  is  input  by  the  user  when 
requesting  the  report  and  is  used  by  the  program  to  select  the  appropriate  survey 
database  records. 

5  In  Part  Two,  the  days  to  get  an  appointment  are  graphed  on  the  Y-axis. 

6  The  responses  to  question  1A  are  averaged  for  each  month  of  the  desired  year 
and  plotted  along  the  X-axis. 

(2)  Waiting  Time  Reports  (see  Figure  72).    As  with  the  access  to  care 

reports,  there  are  two  waiting  time  reports,  one  for  the  department  as  a  whole,  and  one 

for  each  clinic.    The  format  of  the  waiting  time  report  is  similar  to  the  access  to  care 

report  for  both  department  and  clinic.   Part  One  of  the  report,  Acceptability  of  Waiting 

Time  indicates  to  the  Department  Chief  the  patients'  opinions  of  the  acceptability  of 

the  length  of  time  it  took  them  to  be  seen  by  the  doctor.    Part  Two,  Average  Waiting 

Time,  denotes  the  trend  over  the  calendar  year  of  the  average  waiting  time  to  see  a 

doctor. 
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Acceptability  of  Waiting  Time 
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1  Acceptable 

ESB  Not  Acceptable 

— ' *~~  Total  Responses 

Average  Waiting 

Time 

>  1 

hour 


<   1 
hour 


<  45 


<  30  — 


<   15 


Waiting  Time  (minutes) 


JAN 


FEB 


MAR  APR  MAY 

Months 

© 

1989 
'      Average  Waiting  Time 
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Figure  72.    Waiting  Time  Reports 
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The  following  fields  are  necessary  for  creating  the  two  part  waiting 
time  reports. 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 

•  Waiting  Time. 

•  Waiting  Acceptability.  Required  only  for  Part  One,  Acceptability  of  Waiting 
Time. 

The  following  numbered  items  correspond  to  the  numbers  shown 

in  Figure  72  and  explain  the  data  manipulations  and  calculations  required  to  produce 

the  report. 

i  The  total  number  of  responses  for  each  possible  answer  to  survey  question  3A 
are  graphed  along  the  Y-axis  based  on  note  2  below. 

2  For  each  possible  answer  to  question  3A,  the  number  of  patients  who 
responded  to  question  3B  as  acceptable  and  unacceptable  are  counted  and  each 
count  is  graphed  as  a  separate  bar.  For  example,  in  the  figure,  for  those  patients 
that  said  it  took  them  less  than  30  minutes  to  see  a  doctor,  17  said  this  was 
acceptable  and  three  said  this  was  unacceptable. 

3  The  total  response  line  shows  the  total  responses  for  each  possible  answer  to 
question  3A,  waiting  time. 

4  This  is  the  month  and  year  of  the  survey.  This  data  is  input  by  the  user  when 
requesting  the  report  and  is  used  by  the  program  to  select  the  appropriate  survey 
database  records. 

5  In  Part  Two,  the  waiting  time  is  graphed  on  the  Y-axis. 

6  The  responses  to  question  3A  are  averaged  for  each  month  of  the  desired  year 
and  plotted  along  the  X-axis. 

(3)  Satisfaction  Indicators  (see  Figure  73).  Questions  four  through  ten 

of  the  survey  are  statements  for  which  the  patient  is  asked  to  indicate  his  level  or 
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degree  of  satisfaction  ranging  from  five  for  excellent  to  one  for  unsatisfactory.  The 
Satisfaction  Indicator  report  shows  the  results  of  the  survey  in  these  seven  areas,  with 
the  total  number  of  responses  for  each  level  of  satisfaction  (one  through  five)  graphed 
for  each  of  the  seven  areas. 


Satisfaction  Indicators 
_  July  1989 

(D  © 

Number  of  Responses 
30 


Recept 


Nurses 


Doctor  Explain      Time  Spent        Clean 

Satisfaction  Indicators  (.3  J 


Overall 


4       Satisfaction  Levels 
WM  Excellent        ErJ  Good        1      1  OK        B  Need  Improvement        fcS":l  Unsat 

Figure  73.  Satisfaction  Indicators 

The  following  fields  are  necessary  for  creating  this  report: 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 

•  Receptionist  Courtesy. 
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Nursing  Courtesy. 
Doctor  Courtesy. 
Procedure  Explanations. 
Time  Spent  With  Doctor. 
Clinic  Cleanliness. 
Overall  Satisfaction. 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 
73  and  explain  the  data  manipulations  required  to  produce  the  graph. 

1  The  Month  and  Year  for  the  report. 

2  The  total  number  of  responses  in  each  level  of  satisfaction  are  graphed  along 
the  Y-axis. 

3  For  each  satisfaction  indicator  (e.g.,  doctor  courtesy,  overall  satisfaction)  the 
number  of  responses  in  each  level  of  satisfaction  (note  4  in  the  figure)  are 
counted  and  the  total  for  each  level  is  graphed  as  a  separate  bar  for  all  of  the 
indicators  along  the  X-axis. 

(4)  Average  Satisfaction  Levels  (see  Figure  74).    This  two  part  report 

shows  the  average  level  of  satisfaction  for  each  satisfaction  indicator  for  the  calendar 

year.   It  is  presented  in  two  reports  to  simplify  viewing.   The  Department  Chief  prefers 

line  graphs  to  enhance  trend  identification  so  the  seven  indicators  are  divided  into  two 

groups.    Part  One  shows  the  indicators  which  are  primarily  personnel  oriented  (e.g., 

courtesy)  plus  overall  satisfaction.   Part  Two  shows  the  remaining  indicator's  averages. 

The  following  fields  are  necessary  to  create  the  two  part  report: 

•  Month. 

•  Year. 

•  Section  Code.  For  clinic  report  only. 
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Receptionist  Courtesy.  For  Part  One  only. 
Nursing  Courtesy.  For  Part  One  only. 
Doctor  Courtesy.  For  Part  One  only. 
Overall  Satisfaction.  For  Part  One  only. 
Procedure  Explanations.  For  Part  Two  only. 
Time  Spent  With  Doctor.  For  Part  Two  only. 
Clinic  Cleanliness.  For  Part  Two  only. 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 
74  and  explain  the  data  manipulations  required  to  produce  this  report. 
\  This  is  the  requested  year  of  the  survey  data  for  the  report. 

2  The  average  of  all  of  the  values  (ranging  from  one  to  five)  for  each  indicator 
is  calculated  for  each  month  of  the  specified  year.  The  satisfaction  indicators  are 
plotted  along  the  X-axis  using  different  line  styles  for  each  indicators  average 
values. 

3  The  average  response  for  each  indicator  is  correlated  to  it's  equivalent  narrative 
description,  i.e.,  1  =  unsatisfactory,  and  these  are  shown  along  the  Y-axis. 

(5)  Doctor  Satisfaction  Report  (see  Figure  75).    This  report  is  a  table 

showing  the  average  responses  for  a  given  month  for  four  of  the  satisfaction  indicators 

which  most  directly  relate  to  the  patient's  interactions  with  the  doctors.    This  report 

is  produced  for  all  of  the  doctors  in  the  department  and  allows  the  Department  Chief 

to  track  individual  doctor's  survey  results. 
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Figure  74.    Average  Satisfaction  Levels  Report 
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DOCTOR    SATISFACTION   REPORT 
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Figure  75. 

Doctor  Satisfaction  Report 

The  following  fields  are  necessary  for  creating  this  report: 
Year. 
Month. 

Doctor  Name. 
Doctor  Courtesy. 
Procedure  Explanations. 
Time  Spent  With  Doctor. 
Overall  Satisfaction. 

The  numbered  items  below  correspond  to  Figure  75  and  explain 
how  the  data  for  the  report  is  obtained. 

1  This  is  the  month  and  year  for  the  report. 

2  Each  doctor's  name  is  printed  in  the  first  column  in  alphabetical  order. 

3  For  each  doctor,  the  average  response  for  the  four  indicators  is  calculated  and 
placed  in  the  corresponding  column  adjacent  to  the  doctors  name. 

4  The  value  of  all  four  indicators  is  averaged  to  produce   an  overall  doctor 
satisfaction  average. 

5  An  additional  indicator  of  a  physician's  consistency  could  be  computer  here, 
e.g.,  standard  deviation  or  some  similar  measure  of  dispersion. 
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(6)  Patient  Comments  (see  Figure  76).  This  report  is  a  print  out  of 
all  of  the  patient  comments  entered  into  the  survey  database  for  the  desired  month  and 
year.  It  allows  the  Department  Chief  to  review  any  constructive  criticisms  or 
noteworthy  suggestions  made  by  the  patients  and  pinpoint  other  trouble  areas  (or 
outstanding  areas)  which  cannot  be  identified  from  the  quantitative  portion  of  the 
survey. 

The  fields  necessary  to  produce  this  report  are  listed  below: 

•  Month. 

•  Year. 

•  Patient  Comments  to  Enter? 

•  Comments. 

The  numbered  items  below,  corresponding  to  Figure  76,  explain 

the  comment  report. 

i  The  month  and  year  of  the  report  is  listed  at  the  top. 

2  The  records  in  the  database  which  have  the  Comments  field  filled  (indicated 
by  a  "Y"  in  the  Patient  Comments  to  Enter  field)  are  printed  in  record  number 
order  for  the  month  and  year. 

PATIENT  COMMENTS 
■IN   July  1989 


I  THINK  THE  LAB  AND  PHARMACY  TAKE  TOO  LONG,  I  WAITED  FOR  MORE  THAN  AN  HOUR 
TO  GET  MY  PRESCRIPTION  FILLED. 

THE  FAMILY  PRACTICE  CLINIC  IS  GREAT  HERE.   I  WOULD  LIKE  TO  BE  ABLE  TO  SEE 
MY  ASSIGNED  DOCTOR  MORE  OFTEN,  DR.  YEASH,  BUT  WHOEVER  SEES  ME  IS  ALWAYS 
VERY  COURTEOUS  AND  HELPFUL. 

I  NEVER  GET  TO  SEE  THE  DOCTOR  WHICH  MY  FAMILY  IS  ASSIGNED  TO,  WHY  BOTHER 
GOING  THROUGH  THE  HASSLE  OF  SIGNING  UP  FOR  A  SPECIFIC  DOCTOR? 

ITS  TOO  COLD  IN  THE  EXAMINING  ROOMS. 

Figure  76.    Patient  Comments  Report 
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6.    Productivity  Information  System  (see  Program,  Appendix  G) 
a.      Data  Structures 

The  productivity  system  UCD  is  shown  in  Figure  77.  The  functions 
of  the  productivity  system  depend  on  visit  information  obtained  from  the  Patient 
Administration  Division  for  each  section  of  the  department.  The  method  of  obtaining 
the  visit  information  is  described  in  the  next  section,  Inputs. 
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Figure  77.  Productivity  System  User  Concept  Diagram 
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The  visit  information  is  entered  into  the  visit  database  which  consists 
of  the  following  fields: 

•  Fiscal  Year.  The  fiscal  year  is  used  so  the  number  of  visits  in  each  section  can 
be  directly  compared  to  the  section's  expenditures  for  each  month. 
Expenditure  data  is  maintained  in  the  budget  database  by  fiscal  year. 

•  Month. 

•  Section  Code. 

•  Number  of  Visits.  The  number  of  patient  visits  for  each  section  within  the 
department  as  reported  by  the  Patient  Administration  Division. 

b.      Data  Inputs 

The  productivity  system  menu  hierarchy  chart  is  shown  in  Figure  78. 
Visit  data  for  the  entire  hospital  is  collected  monthly  by  the  Patient  Administration 
Division  (PAD)  for  RMD.  PAD  enters  each  section's  visit  information  into  a 
spreadsheet  program  which  they  use  to  create  the  MED  302  report,  discussed  in 
Chapters  EI  and  IV.  For  the  department  productivity  system,  the  visit  information  can 
be  extracted  from  the  PAD  MED  302  file  for  entry  into  the  visit  database.  Table  VI 
shows  the  locations  of  visit  data  in  the  MED  302  spreadsheet  file  corresponding  to 
each  section  in  the  DFPCM.  As  can  be  seen  in  the  Table  VI,  some  calculations  on 
the  data  in  the  file  are  necessary  to  accurately  correlate  the  visit  data  to  the  DFPCM 
sections.  For  example,  the  CTMC  section  visit  count  is  a  combination  of  multiple 
lines  and  columns  from  the  MED  302  file.  The  disparity  occurs  because  PAD  divides 
section  visits  into  subdivisions  for  their  hospital  reporting  requirements.  For  the 
Department  Chief's  purposes,  only  the  total  visit  information  for  each  section  is 
necessary. 
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Table  VI.    MED  302  DATA  EXTRACTION  LOCATIONS 

SECTION  CODE  LOCATION  IN  MED  302  (LINE  #'s  &  COL's) 


FPC 

CFP 

EMS 

FSO 

GOC 

POM 

CTM 

FHL 


SUM  (134  A  &  B  TO  140  A  &  B) 

SUM  (134C  TO  140C) 

SUM  (147  A  &  B) 

SUM  (148  A  &  B) 

SUM  (141  A  &  B) 

141D 

SUM  (141C,  171C,  174C,  141F) 

SUM  (141 E,  171 E,  174E) 
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Figure  78.  Productivity  Menu  Hierarchy  Chart 

The  visit  information  in  the  MED  302  file  can  be  extracted  for  entry 

into  the  visit  database  in  one  of  two  general  ways,  either  automatically  or  manually. 
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To  extract  the  visit  data  automatically,  an  extraction  program  can  be 
written  to  take  data  from  the  MED  302  spreadsheet  file  and  load  it  on  a  floppy  disk. 
Another  program  is  necessary  to  transfer  the  data  from  the  disk  into  the  department 
productivity  system's  visit  database  in  the  correct  format. 

Manual  extraction  would  require  PAD  to  print  the  department's  sections 
and  visit  data,  monthly,  to  a  paper  report.  The  user  of  the  department  productivity 
system  would  select  the  "Add  Visit  Data"  option  from  the  "Update  Visit  Data"  menu 
and  enter  the  visit  data  contained  in  the  printed  report  provided  by  PAD.  The  input 
screen  for  adding,  changing,  or  removing  visit  data  is  shown  in  Figure  79. 


Fiscal  Y«ar 

Month 

Section  Code 

«  of  Visits 

■ 

■ 

■ 

■■ 

Family  Practice  Clinic 
General  Outpatient  Clinic 
CTMC  Family  Practice 
Emergency  Medical  Service 
Presidio  of  Monterey 

Section 

FPC 
GOC 
CFP 
EMS 
POM 

Codes 

Consolidated  Troop  Clinic 
Fort  Hunter  Liggett 
Ambulance  Section 
Flight  Surgeon  Office 

CTM 
FHL 
AMB 
FSO 

Figure  79.  Visit  Data  Input  Screen 

Either  of  the  above  input  methods  is  technically  feasible.  However, 
there  are  tradeoffs  in  choosing  one  method  over  the  other.  The  automated  method 
eliminates  the  need  for  manual  entry  of  each  section's  visit  data  every  month.  On  the 
other  hand,  the  amount  of  data  entry  is  relatively  small.  There  are  eight  sections  with 
visit  data  requiring  approximately  11  keystrokes  for  each  section  (see  Figure  79). 
Thus,  in  any  given  month,  it  would  require  approximately  90  keystrokes  to  enter  the 
new  visit  information  into  the  database.      The  main  drawback  to  automating  the 
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information  extraction  lies  in  the  MED  302  file  itself.  PAD  created  the  spreadsheet 
file  for  their  own  use  in  creating  the  hospital's  MED  302  report.  The  DFPCM  has  no 
control  over  PAD's  use  of  the  spreadsheet  file.  Therefore,  any  changes  PAD  might 
make  to  the  file  would  cause  any  extraction  program  referencing  specific  lines  and 
columns  to  fail.  Other  changes  in  the  method  of  visit  data  collection  or  reporting 
would  likely  require  changes  in  the  extraction  programs.  Both  extraction  methods 
require  cooperation  and  coordination  between  the  DFPCM  and  the  PAD,  with  the 
automated  method  requiring  considerably  greater  effort. 

The  method  of  extraction  aside,  once  the  data  is  contained  in  the 
database,  the  user  can  view  the  data  by  selecting  one  of  the  outputs  described  in  the 
following  section. 

c.       Outputs 

(1)  Review  Visit  Data.  The  review  is  an  option  under  the  "Update 
Visit  Data"  menu  and  allows  the  user  to  view  the  entire  visit  database.  All  of  the 
database  fields  are  displayed  in  the  standard  review  format  described  in  Section  C.2.b., 
Review  Screens. 

(2)  Department  Monthly  Visit  Report  (see  Figure  80).  The  monthly 
visit  report  is  a  bar  graph  showing  each  sections'  total  visits  for  the  desired  fiscal  year 
and  month.  This  report  provides  the  Department  Chief  with  a  quick  indication  of  the 
level  of  work  done  by  each  of  the  eight  sections  reporting  visit  information.  All  of 
the  visit  database  fields  are  necessary  to  create  the  monthly  visit  report. 
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The  following  numbered  items  correspond  to  the  numbers  in  Figure 
80  and  explain  the  monthly  visit  report: 
1_  The  month  and  year  for  the  report. 

2  The  total  number  of  visits  (in  thousands)  for  each  clinic  is  plotted  on  the  Y- 
axis. 

3  The  eight  department  sections  are  plotted  along  the  X-axis. 


DEPARTMENT  MONTHLY  VISITS 

July  19S9 


Number  of  Visits  (thousands) 


© 


CTM 


FPC 


EMS 


GOC 


CFP 


FHL 


(3)  Department  of  Family  Practice  Sections 


FSO 


POM 


Figure  80.  Department  Monthly  Visit  Report 

(3)  Visit  Trend  Report  (see  Figure  81).  The  visit  trend  report  is  a 
multiple  graph  report  showing  fiscal  year  trends  in  patient  visits  for  each  section.  To 
simplify  viewing,  only  two  sections  are  shown  on  each  graph  resulting  in  four  graphs 


184 


9> 

>  w 

c 


.0 

E 

z 


t 

<  f 

I'; 

>  f 

«J 


8     8     8 


5 


»  + 

o     I 

c 


B       + 


lO  < 
>  (/> 

C 


o    T 

6 


N         w  •- 


0 


0> 


>  «/> 

IT 


l~J  I 


-^ 


<n     3 


0s 

Figure  81.  Visit  Trend  Report 
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for  the  entire  report.    All  of  the  visit  database  fields  are  required  for  the  visit  trend 
report. 

The  following  numbered  items  correspond  to  the  numbers  in  Figure 
81  and  explain  the  visit  trend  report. 

1  The  fiscal  year  of  the  report. 

2  The  number  of  visits  for  each  clinic  is  plotted  in  the  appropriate  graph  on  the 
Y-axis. 

3  Each  month  of  the  reported  fiscal  year  is  graphed  along  the  X-axis.   There  are 
two  sections  plotted  on  each  graph,  each  with  a  different  trend  line  style. 

(4)  Expenditure/Visit    Comparison    Report    (see    Figure    82).       The 

expenditure/visit  comparison  report  shows  the  dollar  amount  spent  per  patient  visit.   To 

obtain  the  data  necessary  to  produce  this  report,  the  information  in  the  visit  database 

must  be  combined  with  information  from  two  of  the  databases  maintained  by  the 

budget   system:    the   APC   monthly   expenditure   database;    and   the   APC   database. 

Because  of  the  relationship  between  the  APC  and  the  Section  Code,  the  visit  database 

must  first  be  combined  with  the  APC  database  to  relate  the  visit  database  section  code 

with  the  APCs  used  in  the  budget  system.    The  resulting  combination  must  further  be 

combined  with  the  APC  monthly  expenditure  database.    This  combination  is  necessary 

to  relate  the  number  of  visits  for  a  particular  section  code  to  that  section's  expenditures 

for  the  same  month  and  fiscal  year  desired  for  the  report.    The  three  databases  and 

their  field  relationships  are  shown  in  Figure  83. 
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Figure  82.    Expenditure/Visit  Comparison 

The  combined  data  fields  necessary  to  create  the  report  are  listed 
below: 

Fiscal  Year. 

Month. 

Section  Code. 

APC. 

Expenditure. 

Number  of  Visits. 
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The  following  numbered  items  correspond  to  the  numbers  in  Figure 
82  explaining  the  comparison  report. 

1_  The  month  and  fiscal  year  of  the  report. 

2  The  dollar  expenditure  per  patient  visit  is  plotted  along  the  Y-axis.  For  each 
section,  divide  the  monthly  expenditure  by  the  monthly  number  of  visits  to  arrive 
at  the  expenditure  per  visit  amount. 

3  Each  section  is  plotted  along  the  X-axis  with  a  vertical  bar  showing  the  dollar 
expenditure  per  visit. 

VISIT  DATABASE 


FY 

MONTH 

SECTION 
CODE 

#  VISITS 

FY 


APC 


SECTION 
CODE 


APC  DATABASE 


MONTH 


APC 


EXPENDITURE 


MONTHLY  EXPENDITURE  DATABASE 

Figure  83.  Productivity  and  Budget  Database  Relationships 

(5)  Department  Expenditure  and  Visit  Trend  Report  (see  Figure  84). 
The  expenditure  and  visit  trend  report  allows  the  Department  Chief  to  rapidly  assess 
the  general  direction  department  spending  is  taking  in  comparison  to  the  department's 
workload.  The  process  for  obtaining  the  information  for  the  report  is  similar  to  that 
used  in  the  Expenditure/Visit  Comparison  report  discussed  previously.  The  same 
combined  database  fields  are  used  in  both  reports,  however,  the  calculations  for  each 
report  are  different. 
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The  following  numbered  items  correspond  to  the  numbers  in  Figure 
84  and  explain  the  data  calculations  required  to  produce  the  expenditure  and  visit  trend 
report. 

i  The  fiscal  year  of  the  report. 

2  The  dollar  amount  of  department  expenditures  for  each  month  of  the  fiscal 
year.  Sum  the  eight  section's  expenditure  data  for  each  month  to  obtain  the  total 
monthly  department  expenditures. 

3  The  number  of  department  visits  for  each  month  of  the  fiscal  year.  Sum  the 
eight  sections'  visit  data  for  each  month  to  obtain  the  total  monthly  department 
visits. 

4  The  dollar  amount  of  expenditures  and  the  number  of  visits  are  both  plotted 
on  the  Y-axis.  The  numbers  along  the  Y-axis  represent  both  thousands  of  dollars 
and  thousands  of  visits. 
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Figure  84.    Department  Expenditure  and  Visit  Trend  Report 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.      PROJECT  SYNOPSIS 

We  began  our  information  systems  development  project  for  Silas  B.  Hays  by 
studying  the  current  literature  on  information  systems  development  and  hospital 
information  systems.  The  findings  of  this  literature  research  were  presented  in  Chapter 
II.  In  summary,  there  were  a  multitude  of  systems  development  methodologies  from 
which  to  choose.  We  determined  that  a  combination  of  two  commonly  used 
methodologies,  a  traditional  systems  development  life  cycle  and  a  prototyping 
methodology,  would  best  fit  our  needs.  The  life  cycle  methodology  provided  us  with 
the  structured  techniques  to  develop  the  proposed  information  system,  while  prototyping 
allowed  us  to  quickly  develop  the  user  interfaces  necessary  to  rapidly  identify  user 
requirements.  Through  research,  we  determined  that  the  critical  nature  of  the  health 
care  environment  influences  the  information  systems  used  by  hospitals.  There  exists 
a  dichotomy  between  the  goals  and  objectives  of  hospital  administrators  and  health  care 
providers.  This  dichotomy  influences  the  way  in  which  information  systems  are  used 
to  meet  these  differing  objectives.  Additionally,  the  resource  constraints  within  the 
hospital  create  pressures  when  considering  the  use  of  information  systems  by  both 
administrators  and  health  care  providers.  This  was  particularly  true  in  the  case  of  the 
DFPCM,  whose  Chief  is  both  a  health  care  provider,  and  by  necessity,  an  administrator. 

We  conducted  interviews  with  senior  hospital  managers  to  obtain  a  clear  problem 
definition  and  to  focus  our  research.    The  feedback  from  these  discussions  directed  us 
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to  the  Department  of  Family  Practice  and  Community  Medicine  (DFPCM).  This  large, 
multi-service  department  greatly  affects  overall  hospital  operations.  Chapter  III 
provided  a  detailed  look  at  the  DFPCM:  its  structure  and  its  current  information 
systems.  The  Chief  of  the  DFPCM  commands  more  than  150  people  and  manages  an 
annual  budget  of  nearly  half  a  million  dollars.  In  initial  discussions  with  the  Chief, 
he  identified  and  prioritized  his  most  critical  management  concerns:  budget,  equipment, 
personnel,  scheduling,  patient  satisfaction,  and  productivity.  The  information  systems 
relating  to  these  six  management  areas  became  the  subject  of  our  research. 

Discussions  with  the  Department  Chief  and  his  senior  department  personnel 
helped  us  identify  their  requirements  for  information  in  each  of  the  six  areas.  In 
analyzing  their  needs,  and  comparing  the  needs  with  the  current  information  systems, 
we  were  able  to  propose  improvements  to  the  systems  in  Chapter  IV.  Those 
improvements  included:  the  use  of  databases;  simpler  data  collection;  automated  data 
manipulations  (in  some  cases);  concise,  summary  reports;  graphical  reports;  trend 
analysis  capabilities;  and  improved  automated  user  interfaces  (where  applicable). 

The  improvements  proposed  in  Chapter  IV  were  prototyped  in  Chapter  V  to 
produce  a  detailed  requirements  analysis  for  the  six  information  systems  in  the  DFPCM. 
The  databases,  user  interface  screens,  and  outputs  of  the  systems  were  designed  to  help 
us  pinpoint  the  user's  requirements.  The  Department  Chief  and  other  department 
managers  provided  feedback,  allowing  us  to  tailor  the  prototyped  models  to  their 
specifications.  Time  constraints  allowed  only  one  iteration  of  the  prototyping  process. 
Further  iterations  would  further  enhance  the  requirements  analysis  presented  in  Chapter 
V. 
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The  general  conclusions  resulting  from  our  research  are  presented  in  the  following 
section.  The  recommendations  for  follow  on  thesis  study  are  discussed  in  the  last 
section  of  this  chapter. 

B.      CONCLUSIONS 

The  requirements  analysis  presented  in  this  thesis  is  the  first  step  in  the 
development  life  cycle  for  the  DFPCM  information  system.  With  the  existing 
information  system  defined  and  the  requirements  identified  and  analyzed,  the  system 
can  be  fully  designed,  constructed,  and  implemented  to  meet  the  needs  of  the  targeted 
department  users. 

The  process  of  requirements  analysis  is  a  complex  task  which  if  done  poorly  will 
likely  result  in  a  substandard  system  development.  The  complexity  of  this  task  leads 
to  many  difficulties  which  the  analysts  must  face  during  the  development  process. 

Identifying  the  system's  target  audience  and  obtaining  a  clear  problem  definition 
are  essential  first  steps  in  the  process.  Without  a  clear  understanding  of  the  intended 
users  and  their  related  problems,  the  analyst's  energies  and  resources  are  wasted  on 
unimportant  or  non-existent  requirements.  Starting  on  the  right  track  early  in  the 
process  requires  the  involvement  of  senior  management  to  obtain  the  input  from  those 
personnel  who  are  in  a  position  to  identify  problem  areas.  Once  involved  in  the  thesis 
study,  the  senior  managers  at  Silas  B.  Hays  were  quick  to  identify  the  DFPCM  as 
potential  benefitors  of  an  improved  information  system.  Frequent  and  early  interactions 
with  the  users  were  critical  in  identifying  the  detailed  requirements  of  each  of  the 
subsystems  presented. 
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Selecting  the  "best"  development  methodology  is  the  next  hurdle  in  the 
development  process.  Given  the  large  number  of  methodologies  in  existence,  it  is 
doubtful  there  is  one  "best"  method.  Rather,  the  analyst  must  choose  the  methodology 
most  suited  to  the  task  at  hand,  with  which  he  has  the  most  experience,  or  simply,  one 
which  he  feels  most  comfortable  using.  Decisions  such  as  whether  to  use  data  flow 
diagrams  or  user  concept  diagrams  depends  on  a  number  of  factors,  the  bottom  line 
being  whether  or  not  the  analyst  can  use  the  method  effectively  to  build  a  high  quality 
system  acceptable  to  the  intended  users. 

The  use  of  prototyping  in  the  early  stages  of  system's  development  was  shown 
to  be  beneficial  in  identifying  the  inputs,  interfaces,  and  output  requirements  desired 
by  the  intended  users.  Using  separate  software  packages  to  design  the  various 
prototypes  was  time  consuming  and  did  not  allow  direct  integration  of  the  input  and 
output  prototype  programs.  The  use  of  a  dedicated,  integrated  prototype  tool  which 
does  all  of  these  processes  could  have  greatly  enhanced  our  productivity  in  prototype 
development. 

The  project  management  of  the  system  development  is  critical  for  an  efficient  and 
effective  process.  The  division  of  labor,  coordination  of  effort,  and  teamwork  were 
important  issues  throughout  the  project.  When  these  factors  are  missing  or  inadequate 
in  project  development,  schedules  slip  and  resources  are  wasted. 

An  important  influence  in  the  development  project  at  Silas  B.  Hays  is  the 
complexity  of  the  computer  systems  in  place  at  the  hospital.  The  lack  of  integration 
of  these  systems  frustrates  the  development  of  an  information  system  and  ultimately 
causes  more  work  for  the  users  in  duplicating  the  data  collection  and  reporting  efforts. 
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The  integrated  Composite  Health  Care  System  planned  for  implementation  in  the  early 
1990s  does  not  answer  the  needs  of  the  department  managers  today.  The  new  Director 
of  Information  Management  at  Silas  B.  Hays  has  begun  planning  for  solving  the 
integration  problems  using  networking  technology. 

A  valuable  lesson  learned  during  the  writing  of  this  thesis  was  that  the  use  of 
automation  is  not  always  appropriate  in  every  part  of  an  information  system.  In  some 
cases,  automation  would  actually  create  more  work  in  relation  to  any  benefits  gained. 
With  the  intense  workload  of  the  department's  personnel,  every  effort  must  be  made 
to  reduce  the  amount  of  work  required  while  providing  the  best  possible  information 
to  the  department  chief. 

C.      RECOMMENDATIONS  AND  FOLLOW-ON  THESIS  WORK 

The  requirements  analysis  presented  in  this  thesis  should  be  used  to  further  design 
and  implement  a  complete  information  system  for  the  DFPCM.  The  hospital's 
Information  Management  Division  can  use  the  prototype  program  listings,  and  input  and 
output  examples  to  develop  a  working  system  using  the  software  packages  currently 
available  in  the  hospital,  or  they  can  use  the  requirements  to  justify  purchasing  or 
developing  other  software  as  required  to  implement  the  systems.  Possible  follow  on 
thesis  work  in  this  area  includes  designing,  constructing,  and/or  implementing  an 
information  system  from  a  previously  developed  requirements  analysis.  Evaluating  and 
selecting  software  and  hardware  alternatives,  including  thorough  economic  analyses, 
provide  additional  possibilities  for  future  research. 

The  information  which  could  be  provided  to  hospital  managers  by  a  completed 
system  may  be  useful  to  other  hospital  departments.     Follow  on  thesis  work  could 
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involve  expanding  the  initial  requirements  analysis  of  this  thesis  to  other  departments 
or  the  hospital  as  a  whole. 

Additional  follow-on  thesis  work  include:  research  into  the  design  of  an 
optimization  model  for  the  doctor  scheduling  process  and  further  research  into  the 
doctor  productivity  issues  discussed  in  Chapter  IV. 

At  a  minimum,  the  analysis  contained  in  this  thesis  can  be  used  by  senior 
hospital  managers  to  identify  the  shortcomings  of  the  existing  information  systems  in 
providing  department  managers  with  the  high  quality  information  they  require  to 
successfully  manage  the  many  resources  needed  to  accomplish  their  missions. 
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APPENDIX  A.   DATA  DICTIONARY 


BUDGET  DATABASE  FILES 


APC  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE  :  FORMAT  A999 

SECTION 

CHARACTER 

20 

0 

NAME  OF  SECTION  ASSIGNED  TO  APC  CODE 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

POC 

CHARACTER 

15 

0 

POINT  OF  CONTACT 

TELEPHONE 

NUMERIC 

9 

0 

TELEPHONE  NUMBER  :  FORMAT  (999)999-9999 

STATUS 

CHARACTER 

1 

0 

STATUS  CODE      [  A: ACTIVE,  I : INACTIVE  ] 

QTRALLOC  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  ALLOCATION 

QUARTER 

NUMERIC 

1 

0 

QUARTER  WITHIN  THE  FISCAL  YEAR 

ALLOCATION 

MONEY 

11 

2 

BUDGET  ALLOCATION  FOR  THE  QUARTER 

MOEXP  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE 

MONTH 

NUMERIC 

2 

0 

MONTH  THE  EXPENSE  OCCURRED 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  EXPENDITURE 

QUARTER 

NUMERIC 

1 

0 

COMPUTED,  BASED  ON  MONTH 

EXPENSES 

MONEY 

11 

2 

DOLLARS  EXPENDED  FOR  MONTH 
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EQUIPMENT  DATABASE  FILES 


EQUIP  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

EQCODE 

NUMERIC 

7 

2 

EQUIPMENT  REQUEST  NUMBER  (GENERATED) 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

REQDATE 

DATE 

8 

0 

DATE  OF  ORIGINAL  REQUEST 

DESCRIPT 

CHARACTER 

20 

0 

DESCRIPTIVE  NAME  OF  EQUIPMENT  NEEDED 

REQTYPE 

CHARACTER 

4 

0 

TYPE  OF  EQUIPMENT  REQUEST,  i.e.  CEEP 

PRIORITY 

NUMERIC 

2 

0 

PRIORITY  OF  REQUEST  WITHIN  TYPE  OF  EQUIP 

URGCODE 

NUMERIC 

1 

0 

URGENCY  OF  REQUEST  (  0  TO  4  ) 

QTY 

NUMERIC 

3 

0 

QUANTITY  OF  EQUIPMENT  NEEDED 

UNITPRICE 

MONEY 

9 

2 

PRICE  PER  UNIT  OF  EQUIPMENT  REQUESTED 

EXTPRICE 

MONEY 

10 

2 

EXTENDED  PRICE  OF  EQUIPMENT 

STATUS 

CHARACTER 

2 

0 

STATUS  OF  REQUEST  IN  CODED  FORM 

COMMENTS 

CHARACTER 

20 

0 

COMMENTS  ON  REQUEST 

EQHIST  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

DESCRIPT 

CHARACTER 

20 

0 

DESCRIPTIVE  NAME  OF  EQUIPMENT  NEEDED 

REQTYPE 

CHARACTER 

4 

0 

TYPE  OF  EQUIPMENT  REQUEST,  i.e.  CEEP 

QTY 

NUMERIC 

3 

0 

QUANTITY  OF  EQUIPMENT  NEEDED 

EXTPRICE 

MONEY 

10 

2 

EXTENDED  PRICE  OF  EQUIPMENT 

REQDATE 

DATE 

8 

0 

DATE  OF  ORIGINAL  REQUEST 

XFERDATE 

DATE 

8 

0 

DATE  TRANSFERRED  TO  HISTORICAL  FILE 

MO_TO_COMP 

NUMERIC 

3 

0 

MONTHS  IT  TOOK  TO  COMPLETE  REQUEST 

COMMENTS 

CHARACTER 

20 

0 

COMMENTS  ON  REQUEST 
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PERSONNEL  DATABASE  FILES 


PERSONNEL  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

LNAME 

CHARACTER 

20 

0 

LAST  NAME 

FNAME 

CHARACTER 

15 

0 

FIRST  NAME,  MIDDLE  INITIAL 

RANK 

CHARACTER 

3 

0 

RANK  OF  PERSON 

BRANCH 

CHARACTER 

2 

0 

BRANCH  OF  PERSON 

MOS 

CHARACTER 

5 

0 

MILITARY  OCCUPATIONAL  SPECIALTY  CODE 

STATUS 

NUMERIC 

1 

0 

RESIDENCY  CODE  (IF  IN  RESIDENCY  PROGRAM) 

ALOSS 

DATE 

8 

0 

ANTICIPATED  DATE  OF  LOSS 

ARRDATE 

DATE 

8 

0 

ARRIVAL  DATE  IN  DEPARTMENT 

TDA  PARA 

NUMERIC 

3 

0 

TDA  PARAGRAPH  NUMBER  ASSIGNED  TO  PERSON 

TDA_LINE 

CHARACTER 

3 

0 

TDA  LINE  NUMBER  ASSIGNED  TO  PERSON 

TDA  POSN 

NUMERIC 

2 

0 

TDA  POSITION  NUMBER  ASSIGNED  TO  PERSON 

PERSONAL  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

ADDRESS 

CHARACTER 

20 

0 

PERSON'S  ADDRESS  (HOME) 

CITY 

CHARACTER 

20 

0 

CITY  (HOME) 

STATE 

CHARACTER 

2 

0 

STATE  (HOME) 

ZIPCODE 

NUMERIC 

9 

0 

ZIPCODE  +  4  (HOME) 

WIFE 

CHARACTER 

10 

0 

WIFE'S  NAME 

CHILDREN 

CHARACTER 

25 

0 

CHILDREN'S  FIRST  NAMES  AND  AGES 

TELEPHONE 

NUMERIC 

9 

0 

TELEPHONE  NUMBER  WITH  AREA  CODE  (HOME) 

DOR 

DATE 

8 

0 

DATE  OF  RANK 

COMMENTS 

CHARACTER 

30 

0 

COMMENTS  (PERSONAL) 
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TDA  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

TDA  PARA 

NUMERIC 

3 

0 

TDA  PARAGRAPH  NUMBER 

TDA  LINE 

CHARACTER 

3 

0 

TDA  LINE  NUMBER 

TDA_POSN 

NUMERIC 

2 

0 

TDA  POSITION  NUMBER 

JOBJTITLE 

CHARACTER 

20 

0 

OFFICIAL  JOB  TITLE  AS  STATED  ON  TDA 

APC 

CHARACTER 

4 

0 

ACCOUNT  PROCESSING  CODE 

AUTH  BR 

CHARACTER 

2 

0 

AUTHORIZED  BRANCH  OF  SERVICE 

AUTH  GR 

CHARACTER 

2 

0 

AUTHORIZED  GRADE  (RANK) 

AUTH_MOS 

CHARACTER 

6 

0 

MILITARY  OCCUPATIONAL  SPECIALTY  CODE 

AUTH 

CHARACTER 

1 

0 

AUTHORIZED  SLOT  CODE  (FROM  TDA) 

ABSENCE  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  ABSENCE  REQUEST 

TYPE 

CHARACTER 

1 

0 

TYPE  OF  ABSENCE  (CODED) 

START 

DATE 

8 

0 

START  DATE  OF  ABSENCE 

END 

DATE 

8 

0 

END  DATE  OF  ABSENCE 

DURATION 

NUMERIC 

3 

0 

CALCULATE  (START  DATE  -  END  DATE) 

COMMENTS 

CHARACTER 

30 

0 

COMMENTS  ABOUT  ABSENCE  REQUEST 

CMEALLOC  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  CME  FUNDS  ALLOCATION 

ALLOCATION 

MONEY 

11 

2 

CME  FUNDS  ALLOCATION  FOR  THE  FY 
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CMEPEQ  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  REQUEST 

TYPE 

CHARACTER 

1 

0 

TYPE  OF  CME  REQUEST  (ONE  DIGIT  CODE) 

START 

DATE 

8 

0 

START  DATE  OF  CME  TRAVEL 

END 

DATE 

8 

0 

ENDING  DATE  OF  CME  REQUEST 

DURATION 

NUMERIC 

3 

0 

CALCULATED  (END  DATE  -  START  DATE) 

LOCATION 

CHARACTER 

20 

0 

LOCATION  OF  REQUESTED  CONFERENCE 

PURPOSE 

CHARACTER 

20 

0 

PURPOSE  OF  CME  TRAVEL 

TVIMODE 

CHARACTER 

1 

0 

MODE  OF  TRAVEL  (CODED) 

TRAVELCOST 

MONEY 

7 

2 

COST  OF  TRAVEL 

PERDIEM 

MONEY 

7 

2 

PER  DIEM  COSTS  OF  TRAVEL 

REGFEE 

MONEY 

7 

2 

REGISTRATION  FEES 

RE  1MB 

MONEY 

6 

2 

REIMBURSABLE  EXPENSES 

TOTALCOST 

MONEY 

8 

2 

TRAVELCOST+PERDIEM+REGFEE+REIMB 

C_CODE 

CHARACTER 

1 

0 

COST  CODE  (A=ACTUAL  OR  E=ESTIMATED) 

ABSENCE  FliE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

IDCODE 

CHARACTER 

5 

0 

PERSONNEL  IDENTIFICATION  CODE 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  ABSENCE  REQUEST 

TYPE 

CHARACTER 

1 

0 

TYPE  OF  ABSENCE  (CODED) 

START 

DATE 

8 

0 

START  DATE  OF  ABSENCE 

END 

DATE 

8 

0 

END  DATE  OF  ABSENCE 

DURATION 

NUMERIC 

3 

0 

CALCULATE  (START  DATE  -  END  DATE) 

COMMENTS 

CHARACTER 

30 

0 

COMMENTS  ABOUT  ABSENCE  REQUEST 
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SATISFACTION  DATABASE  FILE 


SURVEY  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

MONTH 

NUMERIC 

2 

0 

MONTH  SURVEY  TAKEN 

YEAR 

NUMERIC 

2 

0 

YEAR  SURVEY  TAKEN 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE  (FROM  SURVEY) 

DOCTORNAME 

CHARACTER 

20 

0 

DOCTOR'S  LAST  NAME,  FIRST  NAME,  MI 

APPTDAYS 

NUMERIC 

1 

0 

NUMBER  OF  DAYS  TO  GET  APPOINTMENT 

ACCAPPT 

NUMERIC 

1 

0 

ACCEPTABILITY  OF  DAYS  TO  GET  APPOINTMENT 

RECORDS 

NUMERIC 

1 

0 

WERE  MEDICAL  RECORDS  READY? 

WAITTIME 

NUMERIC 

1 

0 

WAITING  TIME  SCORE 

ACCWAIT 

NUMERIC 

1 

0 

ACCEPTABILITY  OF  WAITING  TIME  SCORE 

RECEPT 

NUMERIC 

1 

0 

COURTESY  OF  RECEPTIONIST  SCORE 

NURSE 

NUMERIC 

1 

0 

COURTESY  OF  NURSES  SCORE 

DOCTORS 

NUMERIC 

1 

0 

COURTESY  OF  DOCTORS  SCORE 

EXPLAIN 

NUMERIC 

1 

0 

EXPLANATIONS  OF  PROCEDURES  SCORE 

TIMESPENT 

NUMERIC 

1 

0 

ADEQUACY  OF  TIME  SPENT  WITH  DOCTOR  SCORE 

CLEAN 

NUMERIC 

1 

0 

CLEANLINESS  OF  CLINIC  SCORE 

SATIS 

NUMERIC 

1 

0 

GENERAL  SATISFACTION  SCORE 

PATCOMMENT 

CHARACTER 

1 

0 

ARE  THERE  PATIENT  COMMENTS  TO  ENTER? 

COMMENTS 

MEMO 

10 

0 

COMMENTS  MEMO  FIELD 

SCORE  :  NUMBER  MARKED  ON  PATIENT' S  SURVEY  QUESTIONNAIRE 
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PRODUCTIVITY  DATABASE  FTLE 


VISIT  FILE 

FIELD 
NAME 

FIELD 
TYPE 

FIELD 

LENGTH/ 

DECIMALS 

DESCRIPTION 
OF  FIELD 

FY 

NUMERIC 

2 

0 

FISCAL  YEAR  OF  VISIT  INFORMATION 

MO 

NUMERIC 

2 

0 

MONTH  OF  VISIT  INFORMATION 

SECTCODE 

CHARACTER 

3 

0 

SECTION  CODE 

VISITS 

NUMERIC 

4 

0 

NUMBER  OF  VISITS  FOR  SECTION  CODE 
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APPENDIX  B.   DISPLAY  SCREENS 


LIST  OF  SCREENS 


ABSENCE   SCREEN  FILE 

APC  SCREEN  FILE 

CHOICE  SCREEN  FILE 

CMEALLOC  SCREEN  FILE 

CMEREQ  SCREEN  FILE 

CONFIRM  SCREEN  FILE 

DELCMERE  SCREEN  FILE 

DELLEAVE  SCREEN  FILE 

DELMOEXP  SCREEN  FILE 

DELQALLO  SCREEN  FILE 

EQUIPMENT  SCREEN  FILE 

EQUIPMENT  UPDATE  FROM  RIR  SCPEEN  FILE 

MOEXP  SCREEN  FILE 

OCCUPIED  SCREEN  FILE 

PERRIR_B  SCREEN  FILE 

PERSON  SCREEN  FILE 

POSITION  SCREEN  FILE 

QTRALLOC  SCREEN  FILE 

SOCIAL  SCREEN  FILE 

SURVEY  SCREEN  FILE 

TDA  SCPEEN  FILE 

TDAINPUT  SCREEN  FILE 

UPCMEREQ  SCREEN  FILE 


ABSENCE  SCREEN  FILE 


Update  and  change  the  absence  information  in  the  Personnel  Database. 


e 

0 

21 

SAY 

" 

e 

3 

4 

SAY 

e 

3 

28 

SAY 

@ 

3 

31 

SAY 

e 

3 

68 

SAY 

@ 

6 

23 

SAY 

e 

6 

46 

GET 

@ 

8 

4 

SAY 

e 

9 

4 

SAY 

n 

e 

13 

11 

SAY 

e 

13 

26 

GET 

e 

13 

38 

SAY 

@ 

13 

51 

GET 

e 

15 

26 

SAY 

" 

e 

15 

35 

SAY 

@ 

15 

39 

SAY 

e 

18 

13 

SAY 

" 

e 

18 

25 

GET 

e 

2 

1 

TO 

4 

@ 

7 

2 

TO  10 

UPDATE  LEAVE  OR  ABSENCE  REQUEST" 

This  is  the  Fiscal  Year" 

ABSENCE->FY   PICTURE  "99" 

Leave  or  Absence  request  for  ID  CODE" 

ABSENCE->IDCODE   PICTURE  "19999" 

Type  of  Request" 

ABSENCE->TYPE  PICTURE  "!" 


L.. Regular  Leave     E. 

P. .Permissive  TDY    C. 

Starting  Date" 

ABSENCE->START 

Ending  Date" 

ABSENCE->END 

Duration" 

ABSENCE->DURATION 

days" 

COMMENT " 

ABSENCE->COMMENT   FUNCTION 

,  "75 

,  12 


.Emergency  Leave 
.Convalescent  Leave 


PICTURE  "999" 


T.. Other  TDY,  not  CME' 
O. .Other" 


APC  SCREEN  FILE 

Update  and  change  the  Account  Processina  Code  information  in  the  Budrjet  Database. 


@   8 

@  8 
@  11 
@  11 

e  14 

@  15 


PICTUPE  "A-999' 


23  SAY  "APC  Code  Entered  ->" 

4  4  SAY   APC->APC   FUNCTION  "P." 

8  SAY  "SECTION" 

20  GET   APC->SECTION 

48  SAY  "Section  Code" 

63  GET   APC->S_CODE 

20  SAY  "Point  of  Contact" 

38  GET   APC->POC 

20  SAY  "Telephone  Number" 

38  GET   APC->TELEPHONE   PICTURE  "( 999 ) -999-9999" 

31  SAY  "Sec" 

30  SAY  "SECTION  CODES" 
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e 

16, 

A 

0 

17, 

4 

a 

ln, 

4 

e 

19, 

4 

@ 

20, 

4 

9 

1, 

1 

e 

3, 

2 

e 

14, 

1 

SAY  "Family  Practice  Clinic  FFC 
SAY  "General  Outpatient  Clinic  GOC 
FAY  "'•TM'~-Family  Practice  CFP 
SAY  "Emergency  Medical  Service  EMS 
SAY  "Presidio  of  Monterey  POM 
TO  13,  78  DOUBLE 
TO  3,  77 
TO  21,  78 


Consolidated  Troop  Clinic  CTM" 

Fort  Hunter  Liggett  Clinic  FHL" 

Ambulance  Section  AMB" 

Flight  Surgeon  Office  FSO" 

Department  DEP" 


CHOICE  SCREEN  FILE 

Generic  user  selection  format  for  the  Personnel  Database. 

@  6, 0  TO  11,  79  DOUBLE 

0  7,10  SAY  "ENTER  YOUR  CHOICE" 

0  8,10  SAY  "1.  MOVE  THE  OLD  PERSON  TO  EXCESS  AND  THE  NEW  PERSON  INTO  THE  SLOT" 

0  9,10  SAY  "2.  PLACE  THE  PERSON  YOU  ARE  WORKING  WITH  INTO  THIS  POSITION  AS  EXCESS  (  OVEPSTFENGTH, 

POSITION  CODE  -  99)" 

@  10,10  SAY  "3.  TRY  ANOTHER  POSITION  " 

0  7,28  GET  ANSWER  PICTURE  "9"  RANGE  1,3 

CMEALLOC  SCREEN  FILE 

Update  and  change  the  Continuing  Medical  Information  funds  allocation  in  Personnel  Database. 

@  1,  28  SAY  "UPDATE  CME  ALLOCATION" 

@  5,  9  SAY  "THE  CME  ALLOCATION  FOR  FISCAL  YEAR" 

0  5,  4  4  SAY  CMEALLOC->FY 

0  5,  47  SAY  "SHOULD  BE  $" 

0  5,  59  GET  CMEALLOC->ALLOCATION 

0  3,  5  TO  7,  7  3     DOUBLE 

CMEREQ  SCREEN  FILE 

Update  and  change  the  CME  request  information  in  the  Personnel  Database. 


0   1 

0  1 
0  3 
0  3 
0  4 
0  6 
0  6 
0  6 
0  8 
0  8 
0  8 
0  8 
0  10 
0  10 
0  10 
0  10 
0  11 
0  13 
0  13 
0  13 
0  13 
0  14 
0  14 
0  14 
0  16 
0  16 
0  16 
0  16 
0  16 
0  16 
0  18 
0  18 
20 
C 


0 
IF 


ELSE 


2 
68 

0 
34 

3 

0 
46 
52 

0 
24 
45 
71 

0 
16 
42 
60 
42 

0 
31 
41 
53 

3 
14 
19 

0 
18 
29 
44 
56 
71 
17 
40 
12 
CODE 
20,  3 


SAY 

SAY 

SAY 

GET 

SAY 

SAY 

SAY 

SAY 

SAY 

GET 

SAY 

GET 

SAY 

GET 

SAY 

GET 

SAY 

SAY 

GET 

SAY 

GET 

SAY 

SAY 

SAY 

SAY 

GET 

SAY 

GET 

SAY 

GET 

SAY 

SAY 

SAY 

=  "A" 

3   SAY 


"SUBJECT:  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR" 

M_FY   PICTURE  "99" 
"1.  Type  of  Travel  Requested " 

CMEREQ->TYPE   PICTURE  " ! " 
"C-Conf erence/Meet ing  Travel   G-General  Mission  Travel  B-Board  Cert  if icat io* 
"2.  ID  CODE  of  person  requesting  the  travel  is" 

M_IDCODE   PICTURE  " ! 9999" 

"4.  Purpose  of  Travel  is" 

CMEREQ->PURPOSE 
".    5.  Registration  Fee   $" 

CMEREQ->REGFEE 
"6.  Destination" 

CMEREQ->LOCATION 
"Mode  of  Travel  is" 

CMEREQ ->TVLMODE 
"F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER" 


Starting  Date' 


"8.  Leave  Dates 

CMEREQ->STAFT 
"Ending  Date" 

CMEREQ->END 
"Duration" 

CMEREQ->DURATION 
"days" 
"13.   TRAVEL  COST  $" 

CMEREQ- >TRAVELCOST 
"PER  DIEM  COST  $" 

CMEREQ->PERDIEM 
"REIMBURSABLES  $" 

CMEREQ->REIMB 
"TOTAL  COST  OF  TRAVEL  $" 

CMEREQ- >TOTALCOST 
"EXPENSES  REFLECT  THE" 

"ACTUAL  COST  OF  TRAVEL" 


0  20,  33   SAY  "ESTIMATED  COST  OF  TRAVEL' 
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ENDIF 

@      0,       0      TO      2,     7  9 

@    1",     If)      TO    21,     59 


CONFIRM  SCREEN  FILE 

Generic  confirmation  screen  for  the  Personnel  Database. 

@  4,0  SAY  MESSAGE 

@  6,0  TO  9,7  9  DOUBLE 

@  7,5  SAY  "Last  Name:  "+LNAME 

@  7,35  SAY  "First  Name:  -+FNAME 

@  8,5  SAY  "Rank:  "+RANK 

@  8,35  SAY  "Branch:  "+BRAHCH 

??  CHR(7) 

@  15,0 

WAIT  "PRESS  RETURN  TO  CONTINUE..." 


DELCMERE  SCREEN  FILE 


Special  delete  CME  request  information  screen  in  Personnel  Database. 

"SUBJECT:  DELETE  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR" 

M_FY   PICTURE  "99" 
"1  .  Type  of  Travel  Requested " 

CMEREQ->TYPE   PICTURE  "!" 
"C-Conf erence/Meeting  Travel   G-General  Mission  Travel  B-Board  Certif icat io" 
"2.  ID  CODE  of  person  requesting  the  travel  is" 

CMEREQ->IDCODE   PICTURE  "!9999" 

"4.  Purpose  of  Travel  is" 

CMEREQ->PURPOSE 
".    5.  Registration  Fee   $" 

CMEREQ->REGFEE 
"6.  Destination" 

CMEREQ->LOCATION 
"Mode  of  Travel  is" 

CMEREQ->TVLMODE 
"F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER" 
"8.  Leave  Dates    Starting  Date" 

CMEREQ->START 
"Ending  Date" 

CMEREQ->END 
"Duration" 

CMEREQ->DURATION 
"days" 
"13.   TRAVEL  COST  $" 

CMEREQ->TRAVELCOST 
"PER  DIEM  COST  $" 

CMEREQ->PERDIEM 
"REIMBURSABLES  $" 

CMEREQ->REIMB 
"TOTAL  COST  OF  TRAVEL  $" 
TOTALCOST 
"DO  YOU  WANT  TO  DELETE  THIS  RECORD"; 

MAYBE  PICTURE  " ! " 
2,  79 
1,  58 


@ 

1 

,   2 

SAY 

e 

1 

68 

SAY 

e 

3 

0 

SAY 

0 

3 

34 

SAY 

@ 

4 

3 

SAY 

e 

6 

0 

SAY 

@ 

6 

46 

SAY 

e 

6 

52 

SAY 

@ 

8 

0 

SAY 

@ 

8 

24 

SAY 

g 

8 

45 

SAY 

8 

8 

71 

SAY 

@ 

10 

0 

SAY 

@ 

10 

16 

SAY 

@ 

10 

42 

SAY 

@ 

10 

60 

SAY 

e 

11 

42 

SAY 

e 

13 

0 

SAY 

e 

13 

31 

SAY 

e 

13 

41 

SAY 

@ 

13 

53 

SAY 

e 

14 

3 

SAY 

e 

14 

14 

SAY 

e 

14 

19 

SAY 

8 

16 

0 

SAY 

e 

16 

18 

SAY 

e 

16 

29 

SAY 

@ 

16 

44 

SAY 

@ 

16 

56 

SAY 

e 

16 

71 

SAY 

@ 

18 

17 

SAY 

e 

18 

40 

SAY 

(3 

20 

17 

SAY 
GET 

@ 

0 

0 

TO 

fi 

19 

10 

TO  2 

DELLEAVE  SCREEN  FILE 


Special  delete  Absence  information  screen  for  the  Personnel  Database. 

UPDATE  LEAVE  OR  ABSENCE  REQUEST" 
This  is  the  Fiscal  Year" 
ABSENCE->FY   PICTURE  "99" 
Leave  or  Absence  request  for  ID  CODE" 
ABSENCE->IDCODE   PICTURE  "19999" 
SAY  "Type  of  Request" 

ABSENCE->TYPE  PICTURE  "!" 


e 

0, 

21 

SAY 

e 

3, 

4 

SAY 

@ 

3, 

28 

SAY 

@ 

3, 

31 

SAY 

@ 

3, 

68 

SAY 

e 

6, 

23 

SAY 

@ 

6, 

46 

SAY 
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"L.. Regular  Leave     E . . Emergency  Leave        T.. Other  TOY,  not  CME' 
"P. .Permissive  TDY    C. .Convalescent  Leave     O.. Other" 
"Starting  Date" 

ABSENCE->START 
"Ending  Date" 

ABSENCE->END 
"Duration" 

ABSENCE->DURATION   PICTURE  "999" 
"days" 
"COMMENT" 

ABSENCE->COMMENT 
4,  75 
.0,  72 

"DO  YOU  WANT  TO  DELETE  THIS  PECOPD"; 
GET   MAYBE  PICTURE  "!" 
@  21,  10   TO  23,  58 

DELMOEXP  SCREEN  FILE 

Special  delete  Monthly  Expenditure  format  for  the  Budget  Database. 
@   2,  20   SAY  "Delete  this  Monthly  Expenditure" 

"A###" 


@ 

8, 

4 

SAY 

e 

9, 

4 

SAY 

@ 

1  3, 

11 

SAY 

e 

13, 

26 

SAY 

@ 

13, 

38 

SAY 

@ 

13, 

51 

SAY 

@ 

15, 

26 

SAY 

e 

15, 

35 

SAY 

0 

15, 

39 

SAY 

e 

18, 

13 

SAY 

e 

18, 

25 

SAY 

e 

2. 

1 

TO 

s 

1. 

2 

TO 

@ 

22, 

17 

SAY 

e 

5, 

26 

SAY  "APC  Code" 

e 

5, 

38 

SAY   MOEXP->APC   FUNCTION  "!" 

PICTURE 

e 

7, 

26 

SAY  "Month" 

@ 

7, 

38 

SAY   MOEXP->MONTH 

@ 

9, 

26 

SAY  "Expenses" 

@ 

9, 

38 

SAY   MOEXP->EXPENSES 

e 

4, 

15 

TO  10,  56     DOUBLE 

e 

18, 

14 

TO  20, 59 

@ 

19, 

19 

SAY  "Delete  this  Record?  (Y/N) 
GET  Maybe  PICTURE  "!" 

"; 

DELQALLO  SCREEN  FILE 

Special  delete  quarterly  allocation  format  for  the  Budget  Database. 


@ 

3, 

19 

SAY 

"Delete  the  Quarterly  Allocation 

e 

4, 

34 

SAY 

"for" 

i? 

5, 

28 

SAY 

"Fiscal  Year" 

@ 

5, 

41 

SAY 

QTPALLOC->FY 

@ 

9, 

27 

SAY 

"Quarter" 

@ 

9, 

39 

SAY 

QTRALLOC->QUARTER 

e 

11, 

27 

SAY 

"APC  Code" 

@ 

11, 

39 

SAY 

QTPALLOC->APC 

@ 

13, 

27 

SAY 

"Allocation" 

@ 

13, 

39 

SAY 

QTRALLOC->ALLOCATION 

e 

1, 

14 

TO  16,  59     DOUBLE 

@ 

7, 

15 

TO 

7,  58 

@ 

18, 

14 

TO  20,  59 

e 

19, 

19 

SAY  ■ 

Delete  this  Record?  (Y/N)  "; 

GET  Maybe  PICTURE  "!" 

EQUIPMENT  SCREEN  FILE 

Update  and  change  the  Equipment  information  in  the  Equipment  Database. 
[EMENU1_1  SCREEN  FILE] 

"E    N    T    E    P         NEW         EQUIPMENT         DATA" 
"EQUIPMENT    CODE    #" 

EQUIP->EQCODE 
"SECT    DATE       ITEM  DESCRIPTION        TYFE    UFGENCY     QTY      UNIT  PRICE' 

EQUIP->SECTCODE 

EQUIP->REQDATE 

EQUIP->DESCRIFT 

EQUIP ->REQTYPE 

EQUIP->URGCODE 

EQUIP->QTY 
"$" 

EQUIP->UNITPRICE 
"STATUS  CODE  COMMENTS" 

EQUIP->STATUS 
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@ 

2, 

17 

SAY 

(3 

4, 

25 

SAY 

8 

4, 

44 

GET 

@ 

6, 

2 

SAY 

e 

7, 

2 

GET 

@ 

7, 

7 

GET 

@ 

7, 

17 

GET 

@ 

7, 

42 

GET 

@ 

7, 

52 

GET 

@ 

7, 

60 

GET 

@ 

7, 

67 

SAY 

e 

7, 

69 

GET 

e 

9, 

21 

SAY 

@ 

10, 

26 

GET 

@ 

10, 

41 

GET   EQUIP->COMMENTS 

0 

14, 

7 

SAY  "URGENCY  CODES 

TYPE  OF  PEOUEST  CODES 

0 

If, 

6 

SAY  "0 

Needed  Now 

MEt'C     MEDCASE 

@ 

17, 

6 

SAY  "1 

1  Year 

CEEF     CEEF 

e 

18, 

6 

SAY  "2 

2  Years 

CAPR     CAPR 

e 

19, 

6 

SAY  "3 

3  Years 

OTHE     OTHER 

@ 

20, 

6 

SAY  "4 

Not  Urgent 

@ 

13, 

4 

TO  21, 

22 

s 

13, 

28 

TO  21, 

52 

@ 

15, 

29 

TO  15, 

51 

s 

15, 

5 

TO  15, 

21 

8 

1, 

0 

TO  11, 

79 

DOUBLE 

e 

3, 

1 

TO   3, 

78 

@ 

13, 

58 

TO  21, 

75 

@ 

15, 

59 

TO  15, 

74 

0 

5, 

24 

TO   5, 

51 

STATUS  CODES" 


FW 
R11 
AP 
OO 
RC 


Paperwork' 
R1-1D" 

Approved  ' 
On  Order" 
Received" 


EQUIPMENT  UPDATE  FROM  RIR  SCREEN  FILE 

Special  update  screen  for  Equipment  when  the  Resource  Information  Report  is  used. 
[EMENU2  2  SCREEN  FILE] 


@ 

3, 

31 

SAY 

@ 

3, 

42 

SAY 

e 

6, 

9 

SAY 

a 

7, 

10 

SAY 

@ 

7, 

21 

SAY 

e 

7, 

44 

GET 

e 

7, 

50 

GET 

@ 

7, 

64 

GET 

@ 

10, 

33 

SAY 

@ 

11, 

27 

GET 

@ 

14, 

12 

SAY 

q 

2 

5 

TO 

@ 

4' 

6 

TO 

"SECTION" 

EQUIP->SECTCODE 
"EQUIP  CODE     ITEM  DESCRIPTION      QTY    UNITPRICE 

EQUIP->EQCODE 

EQUIP->DESCRIPT 

EQUIP->QTY 

EQUIP ->UNITPRICE 

EQUIP->STATUS 
"COMMENTS" 

EQUIP->COMMENTS 
"Press  ESC  to  abort  editing,  ENTER  to  complete  changes 
13,  71     DOUBLE 
4,  70 


STATUS' 


MOEXP  SCREEN  FILE 

Update  and  change  the  monthly  expenditures  in  the  Budget  Database. 

@  2,  22  SAY  "Enter  the  Monthly  Expenditure" 

@  5,  2  6  SAY  "APC  Code" 

@  5,  38  SAY   MOEXP->APC   FUNCTION  "!"   PICTURE  "A###" 

@  7,  26  SAY  "Month" 

@  7,  38  SAY   MOEXP ->MONTH 

@  9,  26  SAY  "Expenses" 

@  9,  38  GET   MOEXP->EXPENSES 

@  4,  15  TO  10,  56     DOUBLE 

<?  21,  15  TO  24,  56 

OCCUPIED  SCREEN  FILE 

Special  output  screen  when  a  TDA  position  is  occupied  in  the  Fersonnel  Database. 

@  6,0  TO  11,79  DOUBLE 

@  7,5  SAY  "THAT  POSITION  IS  ALREADY  OCCUPIED  BY:  " 

@  8,5  SAY  "Last  Name:  "+LNAME 

@  9,5  SAY  "First  Name:  "+FNAME 

Q    10,5  SAY  "Rank:  "+RANK 

@  15,0 

WAIT 

PERRIR_B  SCREEN  FILE 

Special  input  screen  for  personnel  information  when  the  Resource  Information  Report  is  Used. 

@  1,  24  SAY  "UPDATE  FROM  R.I.F.  REPOPT" 

@  3,  0  SAY  "B.  CHANGES  TO  CURRENT  TDA  (OTHER  THAN  LOSSES  OR  GAINS)" 

@  5,  22  SAY  "OLD  POSITION                                NEW  FOSITION" 

@  7,  2  SAY  "PARA    LINE    POSN   IDCOPE    LAST  NAME                RANK    PAFA    LINE    POSN* 

@  9,  3  GET   O  TDA  PAPA  PICTURE  "999" 


208 


e  9 
e    9 

Q  Q 
@    9 

@  9 
@  9 
@  9 
@  9 
@  13 

e    7 

@  7 

@  7 

@  7 

@  7 

@  7 

6  7 

@  5 

@  4 

@  6 

@  e 
@    o 


10  GET  0_TDA_LINE  PICTURE  "99" 

17  GET  0_TDA_POSN  PICTURE  "99" 
23  GET  M  TPCODE  PICTURE  "!9999" 

31  GET  M_LNAME  PICTUF.E  "!!!!!!!!!!!!!!!!!!!!" 

55  GET  M_RANK  PICTURE  "!!!" 

62  GET  M_TDA_PARA  PICTURE  "999" 

69  GET  M_TDA_LINE  PICTURE  "99" 

7  6  GET  M_TDA_POSN  PICTURE  "99" 

18  SAY  "PRESS  RETURN  (BLANK  ALL  ENTRIES)  TO  QUIT" 
7  TO  9,   7 

14  TO  9,  14 

21  TO  9,  21 

2  9  TO  9,  2  9 

52  TO  9,  52 

66  TO  9,  66 

7  3  TO  9,  7  3 

59  TO  9,  59     DOUBLE 

0  TO  10,  7  9     DOUBLE 

1  TO  6,  78 
1  TO  8,  7  8 

21  TO  2,  52 


PERSON  SCREEN  FILE 

Update  and  change  personnel  information  in  the  Personnel  Database. 


@  0 

0  2 

@  2 

@  4 

@  5 

<?  5 

@  5 

@  5 

@  5 

@  8 


@  8 
@  12 
@  14 
@  14 
@  15 
@  15 
@  16 
@  16 
@  18 
@  23 
<?  6 
@  4 
Q  4 
@  4 
@  4 
@      3 


28  SAY    "UPDATE    PERSONNEL" 

4  SAY    "ID    CODE    is" 

15  SAY   PERSON->IDCODE 

5  SAY  "Last  Name  First  Name   MI       RANK    BRANCH      MOS" 
5  GET   PERSON->LNAME 

28  GET   PERSON->FNAME 

48  GET   PERSON->RANK 

56  GET   PERSON->BRANCH 

65  GET   PERSON->MOS 

5  SAY  "Arrival  Date " 

2  3  GET   PERSON ->ARRDATE 

38  SAY  "Anticipated  Date  of  Loss..." 

65  GET   PERSON->ALOSS 

18  SAY  "INDIVIDUAL  IS  ASSIGNED  TO  TDA  POSITION" 

23  SAY  "TDA  Paragraph  Number  is" 

47  SAY   PERSON->TDA_PARA 

23  SAY  "TDA  Line  Number  is" 

42  SAY   PERSON->TDA_LINE 

23  SAY  "TDA  Position  Number  is" 

4  6  SAY   PERSON->TDA_POSN 

6  SAY  "NOTE:  If  Position  Number  is  99,  the  Individual  is  carried  as  excess' 

16  TO  17,  57 
4  TO   6,  7  4 

53  TO   5,  53 

62  TO   5,  62 

4  5  TO   5,  4  5 

2  6  TO   5,  2  6 

3  TO  10,  75     DOUBLE 


POSITION  SCREEN  FILE 

TD*  position  verification  output  screen  for  the  Personnel  Database. 

@  12,0  TO  17,79  DOUBLE 

@  23,5  SAY  "THE  POSITION  CHOSEN  WAS:  " 

@  14,5  SAY  "Job  Title:  "+JOB_TITLE 

@  J5,5  SAY  "Authorize  Branch:  "  +  A"TH  "F 

@  25,30  SAY  "Authorized  Grade:  "+AUIH_GR 

@  IS, 5  SAY  "Authorized  MOS:  "+AUTH_MOS 

@  16,30  SAY  "Authorized  Position:  " 

IF  AUTH  =  1 

??  "YES" 
ELSE 

??  "NO" 
ENDIF 
@  22,0  WAIT 
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QTRALLOC  SCREEN  FILE 

Update  and  change  quarterly  allocation  in  the  Budget  Database. 


@ 

3, 

19 

SAY 

"Enter  the  New  Quarterly  Allocation 

@ 

4, 

34 

SAY 

"for" 

@ 

5, 

28 

SAY 

"Fiscal  Year" 

@ 

5, 

41 

SAY 

QTRALLOC->FY 

e 

9, 

27 

SAY 

"Quarter" 

@ 

9, 

39 

SAY 

QTRALLOC->QUARTER 

@ 

11, 

27 

SAY 

"APC  Code" 

0 

11, 

39 

SAY 

QTRALLOC->APC 

0 

13, 

27 

SAY 

"Allocation" 

0 

13, 

39 

GET 

QTRALLOC->ALLOCATION 

0 

1, 

14 

TO  16,  59     DOUBLE 

0 

7, 

15 

TO 

7,  58 

SOCIAL  SCREEN  FILE 

Update  and  change  personal  information  in  the  Personnel  Database. 


0 

1 

12 

SAY 

0 

1 

57 

SAY 

@ 

3 

28 

SAY 

0 

4 

0 

SAY 

8 

5 

3 

SAY 

0 

6 

3 

SAY 

0 

8 

0 

SAY 

0 

9 

3 

SAY 

0 

11 

2 

SAY 

0 

11 

13 

GET 

0 

11 

38 

SAY 

0 

11 

50 

GET 

0 

13 

2 

SAY 

e 

13 

25 

GET 

0 

13 

45 

SAY 

0 

13 

47 

GET 

0 

13 

51 

GET 

0 

15 

18 

SAY 

0 

15 

35 

GET 

0 

17 

2 

SAY 

0 

17 

14 

GET 

@ 

17 

29 

SAY 

0 

17 

52 

GET 

0 

19 

10 

SAY 

G 

19 

27 

GET 

@ 

0 

0 

TO 

0 

10 

0 

TO  2 

"This  is  the  personal  information  for  ID  CODE" 

FRIVATE->IDCODE   PICTURE  "19999" 
"PRIVACY  ACT  STATEMENT" 

"PRINCIPLE  PURPOSE:  To  maintain  personal  information  on  indivduals  assigned  to' 
"this  command  to  facilitate  counseling,  emergency  notification,  and  social" 
"event  information." 

"WARNING:  This  information  is  of  a  highly  sensitive  nature  and  should  not  be" 
"provided  to  anyone  outside  of  the  chain  of  command  without  approval." 
"Address" 

PRIVATE->ADDRESS   FUNCTION  " ! " 
"Telephone" 

PRIVATE-XTELEPHONE   FUNCTION  "R"   PICTURE  "(999)999-9999" 
"City,  State,  Zip  Code" 

PRIVATE->CITY 


PRIVATE->STATE 

PRIVATE->ZIPCODE   FUNCTION  "] 
"Date  of  Rank" 

PRIVATE->DOR 
"Wife' s  Name" 

PRIVATE->WIFE 
"Children's  Names/Ages" 

PRIVATE->CHILDREN  "FUNCTION  "S24" 
"Comments " 

PRIVATE->COMMENTS 
2,  77 
0,  77 


PICTURE  "99999-9999' 


SURVEY  SCREEN  FILE 

Input  screen  for  the  Patient  Satisfaction  Survey  in  the  Satisfaction  Database. 


0 

1, 

7 

SAY 

0 

1, 

13 

GET 

0 

1, 

18 

SAY 

0 

1, 

23 

GET 

0 

1, 

29 

SAY 

0 

1, 

36 

GET 

0 

1, 

43 

SAY 

0 

1, 

51 

GET 

0 

3, 

18 

SAY 

0 

3, 

58 

GET 

0 

4, 

20 

SAY 

0 

4, 

58 

GET 

0 

6, 

18 

SAY 

0 

6, 

58 

GET 

0 

8, 

18 

SAY 

0 

8, 

58 

GET 

0 

9, 

2.0 

SAY 

@ 

9, 

58 

GET 

"MONTH" 

SURVEY->MONTH   RANGE  1,  12 
"YEAR" 

SURVEY->YEAR 
"CLINIC" 

SUPVEY->SE^TCODE 
"DOCTOR" 

SURVEY ->DOCTORNAME 
"l.A.  Days  to  get  appointment. 

SURVEY->APPTDAYS   RANGE  1,  6 
"B.  Acceptability. 

SURVEY->ACCAPPT   PANGE  1,  2 
"2.    Records  ready  on  time. 

SURVEY ->RECORDS   RANGE  1,  2 
"3. A.  Waiting  time. 

SURVEY ->WAITTIME   RANGE  1,  4 
"B.  Acceptability. 

SURVEY->ACCWAIT   PANGE  1,  2 


l.A. 
B." 
2." 
3. A. 
B.  " 
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@ 

11, 

18 

SAY  " 

@ 

ii, 

58 

GET 

@ 

32, 

18 

SAY  " 

0 

12, 

58 

GET 

e 

13, 

18 

SAY  " 

e 

13, 

58 

GET 

e 

14, 

18 

SAY  " 

9 

14, 

58 

GET 

@ 

15, 

18 

SAY  " 

e 

15, 

58 

GET 

e 

16, 

18 

SAY  " 

@ 

16, 

58 

GET 

e 

17, 

17 

SAY  " 

@ 

17, 

58 

GET 

@ 

20, 

20 

SAY  " 

e 

20, 

58 

GET 

@ 

21, 

19 

SAY  " 

@ 

21, 

55 

GET 

@ 

0, 

4 

TO  22 

@ 

2, 

15 

TO  10 

@ 

10, 

15 

TO  18 

4.  Courtesy,  receptionists.      4.' 
SURVEY->RECEPT   RANGE  1,  5 

5.  Courtesy,  nurses.  5.' 
SURVEY ->HURSE   RANGE  1,  5 

6.  Courtesy,  doctors.  6.' 
SURVEY->DOCTORS   RANGE  1,  5 

7.  Explanation  of  procedures.    7.' 
SURVEY->EXPLAIN   RANGE  1,  5 

8.  Time  spent  with  doctor.       8.' 
SURVEY->TIMESPENT   RANGE  1,  5 

9.  Cleanliness.  9.' 
SURVEY->CLEAN   RANGE  1,  5 

10.  General  satisfaction.        10. 
SURVEY->SATIS   RANGE  1,  5 
ARE  THERE  COMMENTS  TO  ADD?   (Y/N) " 
SURVEY->P AT COMMENT 
(Cntrl  PgDn  to  Enter  Comments)" 
SURVEY ->COMMENTS 
,  7  3     DOUBLE 
,  60 
,  60 


TDA  SCREEN  FILE 

Update  and  change  the  TDA  information  in  the  Personnel  Database. 


@ 

2 

15 

SAY 

"TDA  Listing" 

@ 

4 

10 

SAY 

"Paragraph  Number" 

@ 

4 

27 

SAY 

TDA->TDA  PARA 

@ 

4 

54 

SAY 

"POSITION  TITLE" 

@ 

6 

10 

SAY 

"Line  Number" 

G 

6 

28 

SAY 

TDA->TDA  LINE 

@ 

6 

47 

SAY 

"Job  Title" 

@ 

6 

59 

GET 

TDA->JOB_TITLE 

@ 

8 

10 

SAY 

"Position  Number" 

@ 

8 

28 

SAY 

TDA->TDA  POSN 

@ 

12 

26 

SAY 

"POSITION  CHARACTERISTICS 

@ 

14 

24 

SAY 

"APC  Code" 

@ 

14 

46 

GET 

TDA->APC 

@ 

15 

24 

SAY 

"Authorized  Branch" 

8 

15 

46 

GET 

TDA->AUTH  BR 

e 

16 

24 

SAY 

"Authorized  Grade" 

@ 

16 

46 

GET 

TDA->AUTH  GR 

@ 

17 

24 

SAY 

"Authorized  MOS" 

@ 

17 

46 

GET 

TDA->AUTH_MOS 

e 

18 

24 

SAY 

"Position  Authorized" 

@ 

18 

46 

GET 

TDA->AUTH 

e 

19 

29 

SAY 

"1=YES   0=NO" 

@ 

3 

7 

TO 

9,  34 

@ 

6 

35 

TO 

6,  44 

@ 

5 

45 

TO 

7,  79 

@ 

13 

21 

TO  20,  55 

TDAINPUT  SCREEN  FILE 

Input  screen  for  entering  a  requested  TDA  position  in  the  PErsonnel  Database. 

@  6,0  TO  11,79  DOUBLE 

@  7,5  SAY  "WHAT  POSITION  WILL  THIS  PERSON  OCCUPY  ; 

OR  ENTER  A  ZERO  (0)  TO  QUIT:  " 

@  8,5  SAY  "TDA  Paragraph  Number:"  ; 

GET  M_TDAPARA  PICTURE  "999" 
READ 

*-  SEE  IF  THEY  WANT  TO  QUIT 
IF  M_TDAPARA  =  0 

TRY=.F. 

LOOP 
END  IF 
@  9, 5  SAY  "TDA  Line  Number:"  ; 

GET  M_TDALINE  PICTURE  "99" 
@  10,5  SAY  "TDA  Position  Number:"  ; 
GET  M  TDAPOSN  PICTURE  "99" 
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UPCMEREQ  SCREEN  FILE 

Special  update  screen  for  CME  requests  when  only  actual  costs  are  entered  in  Personnel  Database. 


@  10 
@  10 
@  11 
d  13 
@  13 
@  13 
@  13 
@  14 
@  14 
@  14 
@  16 
@  16 
@  16 
@  16 
@  16 
@  16 
@  18 
18 
20 


@ 

@ 
IF 


2 
68 

0 
34 

3 

0 
46 
52 

0 
24 
45 
71 

0 
16 
42 
60 
42 

0 
31 
41 
53 

3 
14 
19 

0 
18 
29 
44 
56 
71 
17 
40 
12 


SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
GET 
SAY 
SAY 


SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 


-SUBJECT:  APPLICATION  FOR  CONFERENCE/MISSION  TRAVEL  IN  FISCAL  YEAR" 

M_FY   PICTURE  "99" 
"1.  Type  of  Travel  Requested " 

CMEREQ->TYPE   PICTURE  " ! " 
"C-Conf erence/Meet ing  Travel   G-General  Mission  Travel  B-Board  Certif icatio" 
"2.  ID  CODE  of  person  requesting  the  travel  is" 

M  IDCODE   PICTURE  "19999" 


4.  Purpose  of  Travel  is" 

CMEREQ->PURPOSE 

5.  Registration  Fee   S" 

CMEREQ->REGFEE 

6.  Destination" 

CMEREQ-> LOCATION 
SAY  "Mode  of  Travel  is" 
SAY   CMEREQ->TVLMODE 

F-FLY,  G-GOVT  VEH,  P-POV,  O-OTHER' 

8.  Leave  Dates    Starting  Date" 


CMEREQ-> START 
"Ending  Date" 

CMEREQ->END 
"Duration" 

CMEREQ->DURATION 
SAY  "days" 

SAY  "13.   TPAVEL  COST  $" 
GET   CMEREQ->TRAVELCOST 
SAY  "PER  DIEM  COST  $" 
GET   CMEREQ->PERDIEM 
SAY  "REIMBURSABLES  $" 
GET   CMEREQ->REIMB 
SAY  "TOTAL  COST  OF  TPAVEL  $' 
SAY   CMEREQ->TOTALCOST 
SAY  "EXPENSES  REFLECT  THE  " 


C_CODE 
@  20, 


=  "A" 

33   SAY 


"ACTUAL  COST  OF  TRAVEL" 


ELSE 

@ 
ENDIF 
@  0, 
@  19, 


20,33  SAY  "ESTIMATED  COST  OF  TRAVEL' 


0 
10 


TO   2,79 
TO  21,  58 


212 


APPENDIX  C 


BUDGET  PROGRAMS 


TABLE    OF    PROGRAMS 


BMENU.PRO 
BMENU1 . PRG 
BMENU2  .  PRG 
BMENU3.PRG 
BMENU4 . PRO 
BMENU4_1  .  PRG 
BMINU4_2  .  PRG 
BMENU4_3 .  PRG 
BMENU4  4.  PRG 


DISCLAIMER 

The  purpose    of  this  programming   code  is   to 
facilitate   the   understanding   of  the 
requirements  presented  in    Chapter   5   of  this 
thesis.       The   nature   of  this  project   precludes 
it    actual    Implementation    in    DBASE   III+.     To 
fully  implement    the   requirements   the   system 
designer  will    need  a    full    range   of  capabilities 
that    does   not    currently   exist    in   DBASE   111+ . 

DBASE   III+    served   as    the   modeling    tool    by 
which   the   screens   were   generated  and   where 
necessary,    specific   code   was   written    to 
illustrate   a  point.    The   actual    working   code 
merely  acts   as   a   shell    in    which   to   run   the 
menus.    A   close   analysis   of  the  program  code   can 
facilitate   implementation   in   a  more   suitable 
language,    i.e.,    PARADOX,    which    can   support    the 
graphics   and  high   level    relationships   involved 
in   the   various   databases .    Where   the   actual 
requirements  process  may   appear   to  be    unclear, 
comments   were   added   within   the   code   to   explain 
these    areas    to    the    designer . 


Program . 


BMEOT.PRG 


*  Author...:  ELBERT  T.  SHAW  I    JOAN  ZIMMERMAN 

*  Data :  02/14/89 

*  Notice...:  Copyright  (c)  1989,  ELBERT  T.  SHAH  t  JOAN 
ZIMMERMAN,  All  Rights  Reserved 

*  Notes....:  The  main  engine  menu  for  the  Budget  System 
SET  TALK  OrF 

SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  NHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

9  2,  0  TO  14, 79  DOUBLE 

8  3,  18  SAY  [DEPARTMENT  OF  FAMILY  PRACTICE  BUDGET  SYSTEM] 
8  4,1  TO  4,78  DOUBLE 

*  display  detail  lines 

8   7,29  SAY  [1.  UFDATE  FISCAL  YEAR  ALLOCATIONS  1 

e   8,29  SAY  [2.  UFDATE  MONTHLY  EXf ENLITUKES J 

8   9,29  SAY  [3.  UPDATE  APC  INFORMATION  FILE) 

6  10,29  SAY  [4.  PRINT  REPORTS] 

8  12,  29  SAY  '0.  EXIT' 

STORE  0  TO  selectnurn 

8  14,33  SAY  "  select 

8  14,42  GET  selectnurn  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  selectnuni  =  0 
CLEAR  ALL 
RETURN 

CASE  selectnurn  =  1 


*  DO  UPDATE  FY  ALLOCATIONS 
DO  BMENU1 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnurn  -  2 

«   DO  UPDATE  EXPENDITURES 

DO  BMENU2 

SET   CONFIRM   OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnuni  ■  3 
»   DO  APC  INFORMATION  FILE 
DO  BMENU3 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnurn  *  4 

*  DO  PRINT  REPORTS 


DO  BMENU4 


SET  CONFIRM  OFF 

WAIT 

SET    CONFIRM  ON 


ENDDO    T 

RETURN 

*     EOF:     BMENU.PRO 

'Z 


*    Program. 


BKENU1.PRC 


*  Author...:     ELBERT    T.     SHAM    «    JOAN    ZIMMERMAN 

*  Date :    02/14/89 

*  Notice...:    Copyright     (c)     1989,     ELBERT    T.     SHAW    t    JOAN 
ZIMMERMAN,    All    Rights    Reserved   * 

Notes....:         Updates    the    Quarterly   Allocation    File 

SET    TALK   OFr 

SET    BELL    OFF 

SET    ESCAPE    OFF 

USE    QTRALLOC 

M_FY    -    0 

*  Clear  Screen  for  FY  input  an  allow  for  the  user  to  select 
the  Fiscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 

CLEAR 

86,0  to  8, 79  DOUBLE 

§7,15  SAY  "Enter  the  Fiscal  Year  for  the  Allocations:"  ; 

GET  M_FY  PICTURE  "99" 
READ 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8    3,6    SAY     [UPDATE       FISCAL      YEAR       ALLOCA 
T    I    n   N      S] 

8    4,1    TO    4, 78   DOUBLE 

--display  '}"'  3 1 1  1  lne- 
e   7,25  SAY  [1.  ADD  ALLOCATIONS  FOP  FY  ) +STP (M_FY, 2 ) 
8   8,25  SAY  [2.  CHANGE  ALLOCATIONS  TOF  FY  ] +STP (M_FY, 2 ) 
8   9,2  5  SAY  [3.  REMOVE  ALLOCATIONS  FROM  FY  ) +STP (M_FY, 2 ) 
8  10,25  SAY  [4.  REVIEW  ALLOCATIONS  TOR  TY  ] +STR (M_FY, 2 ) 
8  12,  25  SAY  '0.  EXIT' 
STORE  0  TO  selectnurn 
e  14, 33  SAY  "  select 

8  14,42  GET  selectnurn  PICTURE  "9"  RANGE  0,4 
READ 

DO  CASE 

CASE  selectnurn  *  0 
SET  BELL  ON 
SET  TALK  ON 
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enter  its 
"1999" 


CLOSE  ALL 
CLEAR  ALL 
RETURN 

CASE  selectnum  «  1 

*   DO  ADD  INFORMATION 

Adding  -  .T. 
DO  HHII.r  Adding 

CLEAR 

M  APC  -  SPACE (4) 


*-  Get  the  Section  the  User  wants  to  work  with 

8  6,0  TO  10,79  DOUBLE 

8  7,10  SAY  "Enter  the  APC  Number  of  Section  to 

allocation"   GET  M_APC  PICTURE 

8  8,10  SAY  "or  Press  Return  to  QUIT" 
READ 

•-Nothing  entered,  so  QUIT 
ir  M_APC  -  " 

Adding  -  .r. 

LOOP 
ENDIF 

•-Make  sure  the  APC  exists  in  the  Active  File 

USE  APC  INDEX  APC 

SEARCH-  UPPER (M_APC) 

LOCATE  TOR  APC-SEAPCH 

IF  FOUND  () 
CLEAR 

8  6,  0  TO  9,79  DOUBLE 
8  7,5  SAY  "Section:  "+SECTION 
8  7,35  SAY  "Section  Code:  "+S_CODE 
8  8,5  SAY  "Point  of  Contact : "+POC 
8  8, 35  SAY  ; 


"Telephone: "+TRANSFORM(Telephone, " (999) 999-9999") 
ELSE 

•-Warn  User  that  APC  entered  does  not  exixt 
CLEAR 

8  6,0  TO  8,7  9  DOUBLE 

8  7,5  SAY  "APC  requested  is  not  in  the  Master 
File, ; 

Please  Try  again." 
??  CBR(7) 
8  15,0 

HAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

•-Find  out  wish  quarter's  allocation  the  user  wants 
to  add 

M_QTR  «  0 

8  14,  0  TO  16,45 

8  15,5  SAY  "Enter  the  Quarter  You  Wish  to  Add: 

GET  M_QTR  PICTURE  "9" 
READ 
USE  QTRALLOC  INDEX  QTRALLOC 

♦-Filter  out  all  extraneous  information  and 
restrict  to  user  inputs 

SET  FILTER  TO  FY=M_FY  .AND.  QUARTER=-M_QTR 
GO  TOP 

*-Check  and  see  if  the  user  has  already  enterd  a 
allocation  for  this 

*-APC  and  Quarter 
LOCATE  FOR  APC-M_APC 
IF  FOUND  () 

CLEAR 

WAIT  "RECORD  ALREADY  EXISTS,  Press  Return  to 
Change  it  " 

*-If  found,  just  Edit  the  existing  record 

SET  FORMAT  TO  QTRALLOC 

READ 

CLOSE    TORMAT 
ELSE 

•-Create    a    new    record 

SET    FOFMAT    TO   QTRALLOC 

CLEAR 

WAIT  "ADDING  NEW  RECORD,  Press  Return  to 
Continue" 

APPEND  BLANK 

•-What  the  user  has  input,  don't  make  them 
reinput  it 

REPLACE  rY  WITH  M_FY 

REPLACE  APC  WITH  M_APC 

REPLACE  QUARTER  WITH  MQTR 

READ 

CLOSE  FORMAT 
ENDIF 

ENDDO 

SET  FILTEP  TO 


8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. . " 

SET  TALK  ON 
REINDEX 

set  talk  orr 

CLOSE  ALL 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnum  =  2 

*  DO  CHANGE  INFORMATION 

Adding  =  .T. 
DO  WHILE  Adding 
CLEAR 

M_APC  -  SPACE (4) 
8  6,0  TO  10,79  DOUBLE 

8  7,10  SAY  "Enter  the  APC  Number  of  Section  to 
update  its 

allocation"  GET  M_APC  PICTURE  "1999" 

8  8,10  SAY  "or  Press  Return  to  QUIT" 
READ 

IF  M  APC  -  " 

Adding  -  .F. 

LOOP 
ENDIF 

USE  APC  INDEX  APC 

SEARCH-  UPPER (M_APC) 

•-Locate  the  APC  and  verify  its  existence 

LOCATE  FOR  APC-SEARCH 

IT  FOUND  () 
CLEAR 

8  6,0  TO  9,79  DOUBLE 
8  7,5  SAY  "Section:  "+ SECTION 
e  7,35  SAY  "Section  Code:  "+S_C0DE 
8  8,5  SAY  "Point  of  Contact: "+POC 
8  8,35  SAY  ; 

"Telephone: "+TPANSFORM (Telephone, " (999) 999-9999") 
ELSE 

CLEAR 

8  6, 0  TO  8, 79  DOUBLE 

8  7,5  SAY  "AFC  requested  is  not  in  the  Master 
File, ; 

Please  Try  again." 
??  CHRP) 
8  15,0 

WAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

M_QTR  -  0 

8  14,0  TO  16,45 

8  15,5  SAY  "Enter  the  Quarter  You  wish  to  Change: 

GET  M_QTR  PICTURE  "9" 
READ 

USE  QTRALLOC  INDEX  QTRALLOC 
•-Filter  out  all  extraneous  information  and 
restrict  to  user  inputs 

SET  FILTER  TO  FY=M_FY  .AND.  QUARTER-M_QTR 

GO  TOP 

LOCATE  FOR  APC«M_APC 

IF  FOUND!) 

CLEAR 

WAIT  "RECORD  ALRIADY  EXISTS,  Press  Return  to 
Change  it"  SET  FORMAT  TO  QTRALLOC 

READ 

CLOSE  FORMAT 
ELSE 

SET  FORMAT  TO  QTRALLOC 

CLEAR 

WAIT  "ADDING  NEW  RECORD,  Press  Return  to 
Continue" 

APPEND  BLANK 

REPLACE  FY  WITH  M_FY 

REPLACE  APC  WITH  I!_APC 

REPLACE  QUARTER  WITH  M_QTR 

READ 

CLOSE  FORMAT 
ENDIF 

ENDDO 

SET  FILTEP  TO 

CLOSE  ALL 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnum  ■  3 

*  DO  FEMOVE  INFORMATION 
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Mora  -  .T. 
DO  WHILE  Mors 

TLEAP 

M_APC  -  SPACE (4) 

g  6,0  TO  10,79  DOUBLE 

S  7,10  SAY  "Enter  the  APC  Number  of  the  Section 
to  delete  its 

allocation"  GET  M_APC  PICTURE  "!999" 

8  8,10  SAY  "or  Press  Return  to  QUIT" 

READ 

IF  M_APC  -  " 

More  -  .F. 

LOOP 
ENDIF 

USE  APC  INDEX  APC 

SEARCH-  UPPER (M_APC) 

LOCATE  FOR  APC-SEARCH 

IF  FOUND () 
CLEAR 

§  6,  0  TO  9,79  DOUBLE 
8  7,5  SAY  "Section:   "+SECTION 
8  7,35  SAY  "Section  Code:  "+S_C0DE 
8  8,5  SAY  "Point  of  Contact : "+P0C 
8  8,35  SAY  ; 

"Telephone: "+TRANSFORM (Telephone , " (999) 999-9999") 
ELSE 

CLEAR 

8  6, 0  TO  8, 79  DOUBLE 

8  7,5  SAY  "APC  requested  is  not  in  the  Master 
File,  ; 

Please  Try  again." 
??  CHRP) 
8  15,0 

WAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

M_QTR  «  0 

8  14, 0  TO  16,45 

8  15,5  SAY  "Enter  the  Quarter  You  Wish  to  Delete: 

GET  M_QTR  PICTURE  "9" 
READ 

USE  QTRALLOC  INDEX  QTRALLOC 

SET  FILTER  TO  TY-M_FY  .AND.  QUARTER=M_QTR 
OO  TOP 

LOCATE  FOR  APC=M_APC 
IF  FOUND  () 
CLEAR 

Maybe  *  "  " 

SET  FORMAT  TO  DELQALLO 
READ 

CLOSE  FORMAT 
IF  UPPER (Maybe)  ■  "Y" 

DELETE 
ENDIF 
ELSE 

8  20,0  CLEAR 

?  "Can't  find  the  requested  record" 
??  CHR(7) 

WAIT  "Press  any  key  to  try  again..." 
LOOP 
ENDIF 
ENDDO 

•-Give  the  user  a  chance  to  change  their  mind  about 
deleting  data 

YorN  -  "  " 

CLEAR 

8  5,1  SAY  "Permanently  remove  records  marked  for 
deletion  now?  (Y/N) "  GET  YorN  PICTURE 

8  7,1  SAY  "(Process  may  take  a  few  minutes  to 
complete . . )  " 
READ 
IF  YorN  |  "Y" 

SET  FILTER  TO 

8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. ." 

SET  TALK  ON 

REINDEX 

SET  TALK  OFF 
ELSE 

SET  FILTER  TO 

Nodels  -  0 

* — Count  the  number  of  records  to  be  deleted 

?  "Counting...  Please  wait." 

COUNT  FOR  DELETED!)  TO  Nodels 

Permiss  =  "N" 

DO  WHILE  Permiss  -  "N"  .AND.  Nodels  >  0 
CLEAR 


♦Display  all  deleted  records 

? 

DISPLAY  APC,  FY,  QUARTER,  ALLOCATION  FOR 


DELITEP (> 


Permlsa  ■  "  " 

•-Give  user  all  or  some  choice 

8  23,5  SAY  "OK  to  delete  all  these?  (Y/N) 

GET  Permiss  PICTURE  "I" 
READ 

* — IF  not  OK  to  delete  all,  find  out  which 
IF  Permiss  ♦  "Y" 
RecNo  -  0 
8  20,0  CLEAR 

*-Find  Out  which  Records  to  recall 
8  23,5  SAY  "Recall  which  one  (Record 
Numbe  r )  :  " ; 

GET  RecNo  PICTURE  "999999" 
READ 

IF  RecNo  >  0  .AND.  RecNo  <-  RECCOUNTO 
GOTO  RecNo 
IF  DELETED  () 
RECALL 

Nodels  -  Nodels  -  1 
ENDIF 
ELSE 

8  20,0  CLEAR 

e  23,5  SAY  "No  such  record: 
"+STP (RecNO, 4) 

?  CHR(7) 
WAIT 
ENDIF 
ENDIF 
ENDDO  (Permiss  and  No-dels) 
SET  TALK  ON 
CLEAR 

8  2,0  SAY  '  ' 
?  '  PACKING  DATABASE  TO  REMOVE  RECORDS  MAP1CED  FOR 

DELETION' 
PACK 

ENDIF 

SET  TALK  OFF 

SET  CONFIRM  OFF 

WAIT 

SET  CONTIRM  ON 

CASE  selectnum  -  4 
•   DO  REVIEW  INFORMATION 
CLEAR 

MQTP  -  0 

e  6,0  TO  8,7  9  DOUBLE 

8  7,15  SAY  "Enter  the  Quarter  to  Review"; 

GET  M_QTR  PICTURE  "9"  RANGE  1,4 
READ 

SET  FILTER  TO  QUARTER=M_QTR  .AND.  FY-MFY 
•Display  only  those  records  user  desires 
GO  TOP 
BROWSE  NOAPPEND  NOMENU 

SET  FILTER  TO 
SET  CONFIRM  OFF 
WAIT 
SET  CONFIRM  ON 


ENDDO  T 

RETURN 

•  EOF:  BMENU1.PRG 


Program. 


BMSMU2.PRG 


ELBERT  T.  SHAW  4  JOAN  ZIMMERMAN 
0:  14,89 

Copyright  (c)  1989,  ELBERT  T.  SHAW  I    JOAN 
Rights  Reserved 


*  Author . . 

*  Date .... 

*  Notice. . 
ZIMMERMAN,  All 

*  Notes . . , . : 
SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONTIRM  ON 
USE  MOEXP 
CLEAR 

M_FY  =  0 

86, 0  to  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  for  the  Allocations: 

GET  M_FY  PICTURE  "99" 
READ 
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DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

dioa  menu  I-  il»i  oi.J  fid,:  l,.-.J!.,j 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

§    3, 6    SAY     [UPDATE      MONTHLY         EXPENDITU 
RES)  8    4,1    TO    4,78    DOUBLE 

* display  detail  lines 

8   7,25  SAY  [1.  ADD  EXPENDITURES  FOR  rY  ] +STR (M_FY, 2) 

8   8,25  SAY  [2.  CHANGE  EXPENDITURES  FOR  FY  ] +STR (M_rY, 2 ) 

8   9,25  SAY  [3.  REMOVE  EXPENDITURES  FROM  FY  ] +STR (M_rY, 2) 

%    10,25  SAY  [4.  REVIEW  EXPENDITURES  FOR  FY  ] +STR (M_FY, 2 ) 

8  12,  30  SAY  '0.  EXIT' 

STORE    0    TO   selectnum 

e    14,33    SAY    "    select 

8    14,42    OET    selectnum    PICTURE    "9"    RANGE    0,4 

READ 

DO    CASE 

CASE  selectnum  «  0 
CLEAR  ALL 
CLOSE  ALL 
RETURN 

CASE  selectnum  =  1 
«   DO  ADD  INFORMATION 
Adding  ■  .T. 
DO  WHILE  Adding 
CLEAR 

M_APC  =  SPACE (4) 
8  6,0  TO  10,7  9  DOUBLE 
8  7,10  SAY  "Enter  the  APC  of  the  Section  to 


update 
"1999" 


expenditures"   GET  M_APC  PICTURE 

8  8,10  SAY  "or  Press  Return  to  QUIT" 

READ 

IT  M_APC  -  "   " 

Adding  -  .F. 

LOOP 
ENDIF 

USE  APC  INDEX  APC 
SEARCH-  UPPER (M_APC) 
LOCATE  FOR  APC-SEARCH 
IF  FOUND  () 

CLEAR 

8  6,0  TO  9,7  9  DOUBLE 

8  7,5  SAY  "Section:  "+SECTION 

8  7,35  SAY  "Section  Code:  "+S_C0DE 

8  8,5  SAY  "Point  of  Contact: "+POC 

e  8,35  SAY; 


"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 
ELSE 

CLEAR 

8  6,0  TO  8, 79  DOUBLE 

8  7,5  SAY  "APC  requested  is  not  in  the  Master 
File,  Please 

Try  again . " 
??  CBR(7) 
8  15,0 

WAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

M_MONTH  =  0 

8  14,0  TO  16,45 

8  15,5  SAY  "Enter  the  Month  You  Wish  to  Add: 

GET  M_MONTH  PICTURE  "99"  RANGE  1,12 
READ 

USE  MOEXP  INDEX  MOEXP 

SET  FILTER  TO  TY-M_FY  .AND.  MONTH =M_MONTH 
GO  TOP 

LOCATE  FOR  APC-M_APC 
IF  FOUND  () 

CLEAR 

WAIT  "RECORD  ALREADY  EXISTS,  Press  Return  to 
Change  it  "  SET  FORMAT  TO  MOEXF 

READ 

CLOSE  FORMAT 
ELSE 

SET  FORMAT  TO  MOEXP 

CLEAR 

WAIT  "ADDING  NEW  RECORD,  Press  Return  to 
Continue" 

APPEND  BLANK 

REPLACE  TY  WITH  M_FY 

REPLACE  APC  WITH  M_APC 

REPLACE  MONTH  WITH  M_MONTH 

* — Replace  Quarter  based  on  Month  entered 

DO  CASE 

CASE  M_MONTH  >  9 

REPLACE  QUARTER  WITH  1 


CASE   MMONTH    >    6 

REPLACE    QUARTER    WITH    4 

CASE    M  MONTH    >    3 

KEILACE  QUARTER  WITH  3 

CASE  M_MONTH  >-  1 

REPLACE  QUARTER  WITH  2 
ENDCASE 
READ 

CLOSE  FORMAT 
ENDIF 

ENDDO 

SET  FILTER  TO 

8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. ." 

SET  TALK  ON 

REINDEX 

SET  TALK  OFF 

CLOSE  ALL 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 

CASE  selectnuni  -  2 
*   DO  CHANGE  INFORMATION 
Adding  -  .T. 
DO  WHILE  Adding 
CLEAR 

M_APC  =  SPACE (4) 
8  6,0  TO  10, 79  DOUBLE 

8  7,10  SAY  "Enter  the  APC  Number  of  the  Section 
to  update  its  expenditures"  GET  M_APC  PICTURE  "!999" 
8  8,10  BAY  "or  Press  Return  to  QUIT" 
READ 

IF  M_APC  -  "   " 

Adding  -  .F. 

LOOP 
ENDIF 

USE  APC  INDEX  APC 

SEARCH-  UPPER (M_APC) 

LOCATE  FOR  APC-SEARCH 

IF  FOUND () 
CLEAR 

e  6, 0  TO  9,79  DOUBLE 
8  7,5  SAY  "Section:  "+ SECTION 
8  7,35  SAY  "Section  Code:  "+SCODE 
e  8,5  SAY  "Point  of  Contact : "+POC 
8  8,  35  SAY  ; 

"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 
ELSE 

CLEAR 

8  6,0  TO  8, 79  DOUBLE 

8  7,5  SAY  "APC  requested  is  not  in  the  Master 
File,;  Please 

Try  again. " 
??  CHR(7) 
8  15,0 

WAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

M_MONTH  ■=  0 

8  14, 0  TO  16,45 

e  15,5  SAY  "Enter  the  Month  You  Wish  to  Change: 

GET  MMONTH  PICTURE  "99"  RANGE  1,12 
READ 

USE  MOEXP  INDEX  MOEXP 

SET  FILTER  TO  FY-M_FY  .AND.  MONTB-M_MONTH 
GO  TOP 

LOCATE  FOR  APC-M_APC 
IF  FOUND  () 

CLEAR 

WAIT  "RECORD  ALREADY  EXISTS,  Press  Return  to 
Change  it"  SET  FORMAT  TO  MOEXP 

READ 

CLOSE  FORMAT 
ELSE 

SET  FORMAT  TO  MOEXP 

CLEAR 

WAIT    "ADDING   NEW    RECORD,    Press    Return    to 
Continue" 

APPEND    BLANK 

REPLACE    FY    WITH    M_FY 

REPLACE   APC   WITH   M_APC 

REPLACE    MONTH    WITH    M_MONTH 

* — Automatically    Replace    Quarter   based   on   Month 
entered 

DO   CASE 

CASE   M_MONTH    >    9 

REPLACE    QUARTER    WITH    1 
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CASE  M_MONTH  >  6 

REPLACE  QUARTER  WITH  4 

CASE  M_MONTH  >  3 

REPLACE  QUARTER  KITH  3 

CASE  M_MONTH  >=  1 

REPLACE  QUARTER  WITH  2 
ENDCASE 
READ 

CLOSE  rORMAT 
ENCir 

ENDDO 

SET  TILTER  TO 

8  5,0  SAY  "Please  stand  by  vhlla  I  relndex  tha 
file.." 

SET  TALK  ON 
REIHDEX 
SET  TALK  OrF 
CLOSE  ALL 

set  confirm  orr 

WAIT 

SET  CONTIRM  ON 

CASE  selectnum  ■  3 
*   DO  REMOVE  INFORMATION 
More  -  .T. 
DO  WHILE  More 
CLEAR 

M_APC  -  SPACER) 
8  6,0  TO  10,79  DOUBLE 

8  7,10  SAY  "Enter  the  AFC  Number  of  the  Section 
to  remove  its 

expenditures"  GET  M_APC  PICTURE 
"1999" 

8  8,10  SAY  "or  Press  Return  to  QUIT" 
READ 

IF  M_APC  ■  "   " 

More  -  .F. 

LOOP 
ENDIF 

USE  APC  INDEX  APC 

SEAPCH=  UPPER (M_APC) 

LOCATE  FOR  APC=SEARCH 

IF  FOUND!) 
CLEAR 

8  6, 0  TO  9,79  DOUBLE 
8  7,5  SAY  "Section:  "+SECTION 
8  7,35  SAY  "Section  Code:  "+S_CODE 
8  8,5  SAY  "Point  of  Contact : "+POC 
8  8,35  SAY  ; 

"Telephone: "+TRANSFORM (Telephone, "(999)999-9999") 
ELSE 

CLEAR 

8  6, 0  TO  8,79  DOUBLE 

8  7,5  SAY  "APC  requested  is  not  in  the  Master 
File,     Please 

Try  again . " 
??  CHR (7) 
8  15,0 

HAIT  "Press  Return  to  try  again..." 
LOOP 
ENDIF 

M_MONTH  =  0 

8  14,0  TO  16,45 

8  15,5  SAY  "Enter  the  MONTH  You  wish  to  Delete:  "; 

GET  M_MONTH  PICTURE  "99"  RANGE  1,12 
READ 

USE  MOEXP  INDEX  MOEXP 

SET  FILTER  TO  FY=M_FY  .AND.  MONTH=M_MONTH 
GO  TOP 

LOCATE  FOR  APC-M_APC 
IF  FOUND  () 

CLEAR 

Maybe  «  "  " 

SET  FORMAT  TO  DELMOEXP 

READ 

CLOSE  FORMAT 

IF  UPPER (Maybe)  -  "Y" 
DELETE 

ENDIF 
ELSE 

8  20,0  CLEAR 

?  "Can't  find  the  requested  record" 

??  CHR (7) 

WAIT  "Press  any  key  to  try  again..." 

LOOP 
ENDIF 

ENDDO 


YorN  ■=  "  " 
CLEAR 

8  5, 1  SAY  "Permanently  remove  records  marked  for 
deletion  now? 

(Y/N)"; 
GET  YorN  PICTURE  "!" 
8  7,1  SAY  "(Process  may  take  a  few  minutes  to 
complete . . ) " 
READ 
IF  YorN  ♦  "Y" 

SET  TILTER  TO 

8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. ." 

SET  TALK  ON 
REINDEX 
SET  TALK  OFF 
ELSE 

SET  FILTER  TO 
Nodels  -  0 

•--Count  the  number  of  records  to  be  deleted 
1    "Counting...  Please  wait." 
COUNT  FOR  DELETED!)  TO  Nodels 
Permlss  *  "N" 

DO  WHILE  Perraiss  -  "N"  .AND.  Nodels  >  0 
CLEAR 
? 

DISPLAY  APC,  FY,  MONTH,  EXPENSES  FOR  DELETED!) 
1 

Permlss  «  "  " 
8  23,5  SAY  "OK  to  delete  all  these?  (Y/N)  "; 

GET  Permlss  PICTURE  "I" 
READ 

*--IF  not  OK  to  delete  all,  find  out  which 
IT  Permlss  *  "Y" 
RecNo  -  0 
8  2  0,0  CLEAR 

e  23,5  SAY  "Recall  which  one  (Record 
Numbe  r ) :  " ; 

GET  RecNo  PICTURE  "999999" 
READ 

IF  RecNo  >  0  .AND.  RecNo  <-  RECCOUNTO 
GOTO  RecNo 
IF  DELETED)) 
RECALL 

Nodels  =  Nodels  -  1 
ENDIF 
ELSE 

e  20,0  CLEAR 

8  23,5  SAY  "No  such  record: 
"  +  STR(PecNO,  4) 

?  CHR(7) 
WAIT 
ENDIF 
ENDIF 
ENDDO  (Permlss  and  No-dels) 
SET  TALK  ON 
CLEAR 

8  2,0  SAY  '  ' 

?  'PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 
DELETION' 
PACK 

SET  TALK  OFF 
SET  CONFIRM  OFF 
WAIT 
SET  CONFIRM  ON 

CASE  selectnum  =  4 

*   DO  REVIEW  INFORMATION 

USE  MOEXP  INDEX  MOEXP 

CLEAR 

M_MONTH  -  0 

8  6,0  TO  8,7  9  DOUBLE 

e  7,15  SAY  "Enter  the  Month  to  Review"; 

GET  M_MONTH  PICTURE  "99"  RANGE  1,12 
READ 

*-rilter  out  extraneous  information 
SET  FILTER  TO  FY-M_FY  .AND.  MONTH-MMONTH 
GO  TOP 

BROWSE  NOAPPEND  NOMENU 
SET  COTT1  II  OFF 
WAIT 
SET  CONFIRM  ON 


ENDDO  T 

RETURN 

*  EOr:  BMENU2.PRG 


Frogra 


BMZNU3.PRC 
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«  Author...:  ELBEPT  T.  SHAM  t    JOAN  ZIMMERMAN 

•  r** » :  c::i4.'«9 

*  I!  >lce...:     Copyright   fc>  19P9.  ELBEPT  T.  SRAM  I     70AN 
ZIMMERMAN,  All  Rights  Reserved 

«  Notes. . . .  : 

USE   APC    INDEX   APC 

Ret    -   CHR(17)+CHR<196)+CHR<217) 

DO   MHILE    .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  end  print  heading 
M_APC-SPACE(4) 

CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8  3,  12  SAY  [UPDATE   APC   INFORMATION    r 
I  L  E] 

(  4,1  W  4,78  DOUBLE 

*  display  detail  lines 

8   7,30  SAY  [1.  ADD  APC  INFORMATION] 

8   8,30  SAY  [2.  CHANGE  APC  INFORMATION] 

8   9,30  SAY  [3.  REVIEM  ALL  APC  INFORMATION) 

8  16,22  SAY  "[  APC  is  the  Account  Processing  Code  ]" 

8  11,  30  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,3 

READ 

DO  CASE 

CASE  selectnum  -  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  selectnum  =  1 
*   DO  ADD  INFORMATION 
Adding  -  .T. 
DO  MHILE  Adding 

* Ask  for  new  APC  to  add 

CLEAR 

CLOSE  FORMAT 

M_APC  -  SPACE (4) 

e  6, 0  TO  8,79  DOUBLE 

e  7,15  SAY  "Enter  APC  Code  ->  "; 

GET  M_APC  PICTURE  "1999" 
8  15,15  SAY  "Press  Enter  ["+Ret+")  to  return  to 
Menu" 

READ 

•--Create  lookup  variable 
Search  -  UPPEP(M_APC) 

* — If  nothing  entered,  Leave  Program 
IT  Search  «  "  " 

EXIT 
ENDIF 

* — See  if  APC  is  already  Stored 

SEEK  Search 

SET  FORMAT  TO  APC 

*--If  name  Found  Edit 

IF  FOUND  () 

CLEAR 

8  6,0  TO  8,7  9  DOUBLE 

8  7,15 

??  "APC  Code  selected  is  already  in  use. 
Please  try  again..." 

??  CHR(7) 

8  22,0 

MAIT 

LOOP 
ENDIF 

*--If  not  found,  Add  new  APC 
IF  .NOT.  FOUND () 

APPEND  BLANK 

REPLACE  APC  MITH  M  APC 

READ 
ENDIF 

ENDDO 

8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. ." 

SET  TALK  ON 

REINDEX 

SET  TALK  OFF 

LOOP 

CLOSE  FORMAT 


CASE  selectnum  •=  2 

*  DO  CHANGE  INFORMATION 

CLEAR 
Adding  =  .T. 
DO  MHILE  Adding 

* Ask  for  new  APC  to  add 

CLEAR 

CLOSE  FORMAT 
M_APC  -  SPACE (4) 
8  6,0  TO  9,  79  DOUBLE 

8  7,15  SAY  "Enter  the  APC  Code  you  wish  to 
change  : "; 

GET  M_APC  PICTURE  "1999" 
8  8,15  SAY  "Press  Enter  ("+Ret+")  to  return  to 
Menu" 

READ 

•--Create  lookup  variable 

Search  -  UPPER (M_APC) 

* — If  nothing  entered,  Leave  Program 
IF  Search  =  "  " 

Adding  -  .F. 

LOOP 
ENDIT 

* — See  if  APC  is  already  Stored 

SEEK  Search 

SET  FORMAT  TO  APC 

* — If  name  Found  Edit 
IF  FOUND  () 

M_APCSTATUS  »  "  " 
CLEAR 

8  6,0  TO  8,79  DOUBLE 

e  7,15  SAY  "Do  You  wish  to  put  this  APC  Code 
into  inactive 

status  (Y/N) : "  GET  MAPCSTATUS 
PICTURE  "!" 

READ 

•-  IF  KANT  TO  INACTIVATE  APC,  JUST  PUT  A 
INACTIVE 

CODE  INTO  TILE 
•   ELSE  EDIT  THE  FILE  AS  USUAL. 

IF  M_APCSTATUS  =  "Y" 

REPLACE  STATUS  MITH  I 
ELSE 

SET  FORMAT  TO  APC 
READ 

CLOSE  FORMAT 
ENDIF 
ELSE 

*--If  not  found,  warn  user 
8  6,0  TO  8, 79  DOUBLE 
8  7,  15 

?  "Can't  Find  the  APC  you  requested: 
", Search 

??  CHRP) 
MAIT 
ENDIF   (found) 

ENDDO 
CLEAR 

8  5,0  SAY  "Please  stand  by  while  I  reindex  the 
file. ." 

SET  TALK  ON 

REINDEX 

SET  TALK  OFF 

SET  CONFIRM  OFF 

MAIT 

SET  CONFIRM  ON 

CASE  selectnum  -  3 

•  DO  REVIEM  INFORMATION 

SET  HELP  OFF 
GO  TOP 
BROMSE  NOAPPEND  NOMENU 

SET  CONFIRM  OFF 
MAIT 
SET  i~ONF7PM  ON 

ENDCASE 

LOOP 

ENDDO 

RETURN 

*    EOF:    BMENU3.PRG 


m 


Program . 


BMZOTM  .  PPG 
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Author. 


:  ELBERT  T.  SRAM  i  JOAN  ZIMMERMAN 

!  02  14/99 

I  '•-lyrflh*  (fl  1989,  ELBERT  T.  SRAM  t  JOAN 

ALL  Rights  Reserved 


«    1J..I  Jf». 
ZIMMERMAN 

*  Notes.. 

*  Fessned.  :     selectnura 

set  taik  orr 
set  bezl  orr 
set  escape  orr 
set  cgssfirm  on 

do  mhue  .t. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEJ6R 

8  2,  0  TO  14,79  DOUBLE 

8    3,28    SAY     [PRINT         REPORTS] 

8    4,1   TO    4,7  8   DOUBLE 

*  display  detail  lines 

e   7,33  SAY  [1.  MONTHLY  REPORT) 

8   8,33  SAY  [2.  QUARTERLY  REPORT] 

8   9,33  SAY  (3.  riSCAL  YEAH  REPORT  (RECAP)] 

8  10,33  SAY  [4.  PRINT  GRAPHS) 

8  12,  33  SAY  '0.  EXIT' 

STORE  0  TO   select  num 

8    14,33    SAY    "    select  " 

8    14,42    GET    selectnura    PICTURE    "9"    RANGE    0,4 

READ 

DO    CASE 

CASE   selectnum   »    0 
CLEAR   ALL 
RETURN 

CASE    selectnum  »   1 
*      DO   MONTHLY    REPORT 

DO    BMENU4    1 


MAIT 

SET    CONFIRM  ON 

CASE    selectnum    =    2 

«      DO    QUARTERLY    REPORT 

DO    BMENU4_2 

MAIT 

SET    CONFIRM   ON 

CASE    selectnura    *    3 
•      DO    FY    REPORT 

DO    BMENU4    3 


MAIT 

SET    CONTIRM  ON 


CASE    selectnura   =    4 
*      DO    PRINT    GRAPHS 

DO  BMENU4  4 


SET  CONFIRM  OFF 


SET  CONFIPM  OFF 


SET  CONFIRM  OFF 


SET  CONFIRM  OFF 


MAIT 

SET  CONTIRM  ON 


ENDCASE 

ENDDO  T 

RETURN 

*  EOF:  BMENU4.PRG 

"Z 


Program.  . 


BMBKU4  l.PRC 


*  Author...:  ELBERT  T.  SHAM  s  JOAN  ZIMMERMAN 

*  Date :  02/14/89 

*  Notice...:  Copyright  (c)  1989,  ELBERT  T.  SHAM  (.  JOAN 
ZIMMERMAN,  All  Rights  Reserved 

*  Notes  . .  .  .  : 
SET  TALE  OFF 
SET  BELL  OTF 
SET  ESCAPE  OFF 
SET  CONTIRM  ON 
M_TY  -  0 

M_MO  -  0 
CLEAR 

e  6,  0  TO  9,79  DOUBLE 

8  7,15  SAY  "Enter  the  Fiscal  Year  for  the  report"; 
GET  M  TY  PICTURE  "99" 


READ 

8    8,15   SAY   "Enter   the  Month    for   the    report"; 

GET   M   MO    PlrTUPE    "9»"    RANGE    1,12 
PEAD 

***    Restrict    Output    to    selected    FY    and    selected    Month 
***    MONTHLY    REPORT    PRINTED    HERE    *** 

*    EOT:     BMENU4    l.PRG 


Program. . 


MBKU4    2.PRC 


*  Author...:    ELBERT    T.     SHAM    i.    JOAN    ZIMMERMAN 

•  Date ;    02/14/89 

«    Notice...:    Copyright     (c)    1989,     ELBERT   T.    SRAM    4    , 
ZIMMERMAN,    All    Rights    Reserved 

•  Notes 

SET  TALK  OFF 
SET  BELL  OTF 
SET  ESCAPE  OTF 
SIT  CONTIRM  ON 
MTY  -  0 
M_QTR  -  0 
CLEAR 

8  6,  0  TO  9,79  DOUBLE 

8  7,15  SAY  "Enter  the  Tiscal  Year  for  the  report"; 

GET  M_TT  PICTURE  "99" 
HEAD 
8  8,15  SAY  "Enter  the  Quarter  for  the  report"; 

GET  M_QTR  PICTURE  "9"  RANGE  1,4 
READ 

»**  QUARTERLY  REPORT  PRINTED  HERE  *** 

*  EOT :  BMENU4  1 . PRG 


4  3. PRG 


SHAW 


JOAN  ZIMMERMAN 


ELBERT  T.  SHAM  t  JOAN 


Program. 


*  Author. . . :     ELBERT   T 
«    Date :    02/14/89 

*  Notice...:    Copyright     (c)     1989 
ZIMMERMAN,    All    Rights    Reserved 

*  Notes . . . . : 
SET    TALK    OFF 
SET    BELL   OTF 
SET   ESCAPE    OTT 
SET    CONFIRM   ON 
M_FY    =    0 

*  CLEAR    THE    SCREEN    TO   ACCEPT    THE    FY    INPUT 

*  DETERMINE    THE    FY    OF    THE    REPORT 
CLEAR 

8    6,0    TO    8,7  9    DOUBLE 
8    7,15    SAY    "Enter   the    Fiscal 

GET   M_TY    PICTURE     "99" 
READ 
DO   MHILE     .T. 

* Display   menu    options 

*  draw   menu    border    and   print    heading 
CLEAR 

8    2,     0    TO    12,79    DOUBLE 

8    3,8    SAY     [FISCAL         YEAR  PEPOR 

8    4, 1    TO    4, 78   DOUBLE 

*  display  detail  lines 

8   7,33  SAY  [1.  FISCAL  YEAP  ALLOCATION  REPORT] 

e   8,33  SAY  [2.  FISCAL  YEAR  RECAP] 

e  10,  33  SAY  '0.  EXIT' 

STORE  0  TO  selectnura 

e  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE    selectnura   *    0 
SET    BELL    ON 
SET    TALK    ON 
CLEAR   ALL 
RETURN 


ear  for  the  reports"; 


centered  on  the  screen. 


T  S] 


CASE    selectnura    = 
*       DO   ALLOCATION 


FY   ALLOCATION    REPORT    PRINTED    HERE 
SET    CONFIRM   OTF 
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SET  CONFIRM  ON 

CASE    selectnum    -    2 
*       D'.'    EX1  EMUT'M  1.3 

***    FY    RECAP    REPORT    PRINTED    HERE    *** 
SET   CONFIRM   OFF 
WAIT 
SET    CONFIRM   ON 


ENDDO  T 

RETURN 

»    EOF:     BMENU4_3.PRG 

"Z 


Program. 


MONTH    4. FRO 


*  Author...:     ELBERT    T.     SHAH    i    JOAN    ZIMMERMAN 
»    Date :    02/14/89 

*  Notice...:    Copyright    (c)    1989,    ELBERT  T.    SHAW    t    JOAN 
ZIMMERMAN,    All    Rights    Reserved 

*  Notes 

SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_FY  -  0 
M_QTR  ■  0 
M_RANGE  -  0 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

e  3,29  SAY  [PRINT    GRAPHS) 

8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,24  SAY  [1.  PERCENT  SPENT  FOF  QUARTER.  (BAP  GRAPH)) 

8   8,24  SAY  (2.  TREND  GRAPHS  (LINE  GRAPH)) 

8  10,  24  SAY  '0.  EXIT' 

STORE  0  TO  selectman 

8  12,33  SAY  "  select 

e  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,3 

READ 

DO  CASE 

CASE  selectnum  ■=  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  selectnum  -  1 

*  DO  PERCENT  SPENT  FOR  QTP   (BAR  GRAPH) 

*  Clear  Screen  for  FY  and  QTF  input 
CLEAR 

86, 0  to  9, 79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  of  the 
Expenditure: "; 

GET  M_rY  PICTURE  "99" 
READ 
8  8,15  SAY  "Enter  the  Quarter  to  Review"; 

GET  M_QTR  PICTURE  "9"  RANGE  1,4 
READ 

»»•  DETERMINE  EXPENDITURE  BY  SECTION  TOR  EACH 

SECTION  FOR  THE  QUARTER  SELECTED,  HIS  FIGURE 
COULD   BE  A  PARTIAL  OUTLOOK  FOR  THE  CURFENT 
QUARTER  COMPARE  TO  CURRENT  SECTION'S  ALLOCATION 
AND  DETERMINE  PERCENTAGE  SPENT 

***  PERCENT  SPENT  FOP  CHAPTER  GPAFH  HERE 

SET  CONFIRM  OFF 
WAIT 

READ 

SET  CONFIRM  ON 

CASE  selectnum  «  2 

*  DO   TREND     (LINE    GRAPH) 

M_FY  -  0 

*  Clear  Screen  for  FY  input 
CLEAR 

86,0  to  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  of  the  Report:"; 


GET  M  TY  PICTURE  "99" 


••    T^TAI.    AM.    SECTION    EXFFNDTTnT'Ff:    PY    H"NTH    T" 

DtiLuiiiiE  t-riMinrin    "'   r.xt  twi  n  t  ■■■  ►-.•!    t.v  n 

MONTH  OF  FY.  ALSO  GRAPH  TOTAL  ALLOCATION  FOR 
*•  DEPARTMENT  TOR  EACH  QUARTER. 

***  PRINT  YEARLY  TREND  LINE  GRAPH  HERE 


*   DO  LONG  TERM  TREND  (TREND  GRAPH) 

«**  LOCATE  ALL  DATA  FOR  CURRENT  FISCAL  YEAR,  AND 

PREVIOUS  TISCAL  YEARS  UP  TO  THE  TWO  YEARS 

FROM  CURRENT  YEAR 
*«»  TREND  ON  MONTHS  EXPENDITURES,  DISPLAY 

ALLOCATIONS  FOR  THOSE  YEARS 
*•*  INDIVIDUAL  APC  EXPENDITURES  ARE  TOTALED  TO  GET 

DEPARTMENT  WIDE  PICTURE 
***  PRINT  LONG  TERM  TREND  GRAPH  HERE  *** 

SET  CONFIRM  OFF 

WAIT 

SET  CONFIRM  ON 


ENDCASE 


ENDDO  T 

RETURN 

»  EOF:  BMENU5.PRG 

-z 
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APPENDIX  D.   EQUIPMENT  PROGRAMS 


TABLE  OF  PROGRAMS 


EMENU. 
EMENU  1 
EMENU  1 
EMENU1 
EMENU2 
EMENU  2 
EMINU2 
EMENU3 
EMENU3 
EMENU3 
EM3_2_ 
EMENU3 
EMZNU3 
EM3_4_ 
EMENU3 
EMINU  4 


PRO 
.PRO 
_2 . PRO 
~3 .  PRO 
.PRO 
_1 . PRO 
_2 . PRO 
.PRG 

1 .  PRG 
_2 . PRG 
l.PRG 

3.  PRG 
_4 . PRG 
l.PRG 

5.  PRG 

PRG 


DISCLAIMER 

The  purpose    of   this   programming    code    is    to 
facilitate   the    understanding   of  the 
requirements  presented  in    Chapter   5   of  this 
thesis.       The  nature   of  this  project  precludes 
it    actual    implementation    in   DBASE   111+ .    To 
fully  implement    the   requirements   the   system 
designer   will    need  a    full    range   of  capabilities 
that    does   not    currently   exist    in   DBASE   III+ . 

DBASE   Ill-t-    served  as   the  modeling   tool   by 
which   the   screens   were   generated  and  where 
necessary,    specific    code    was    written    to 
Illustrate   a  point.    The   actual    working   code 
merely  acts   as   a    shell    in    which    to   run   the 
menus.    A   close   analysis   of  the  program   code   can 
facilitate  implementation   in    a  more   suitable 
language,    i.e.,    PARADOX,    which    can   support    the 
graphics    and   high    level    relationships    involved 
in    the   various    databases .    Where   the   actual 
requirements  process  may   appear   to  be    unclear, 
comments   were   added   within   the   code   to   explain 
these   areas   to   the   designer . 


Program. . 


EMEKU.PRG 


ELBERT  T.  SHAW  S  JOAN  ZIMMERMAN 

02/16/89 

Copyright  (c)  1989,  All  Rights  Reserved 


*  Author. . . 

*  Date 

*  Notice. . . 

*  Notes .... 
SET  TALK  OrF 
SET  BELL  OFT 
SET  STATUS  OrF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 


*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

(  2,  0  TO  14, 79  DOUBLE 

8  3,13  SAY  [DEPARTMENT  OF  FAMILY  PRACTICE  PLANNED 
EQUIPMENT  SYSTEM] 

8  4,1  TO  4, 78  DOUBLE 

*  display  detail  lines 

t   7,27  SAY  [1.  UPDATE  EQUIPMENT  LISTING] 

8   8,27  SAY  [2.  UPDATE  PRIORITIES) 

e   9,27  SAY  [3.  PRINT  REPORTS] 

e  10,27  SAY  (4.  ARCHIVE  HISTORICAL  DATA] 

8  12,  2  7  SAY  '0.  EXIT' 

STORE    0    TO    select  najii 

S  14, 33  SAY  "  select 


S  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,4 
READ 

DO  CASE 

CASE  selectnum  -  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  selectnum  *  1 

*  DO  UPDATE  EQUIPMENT  LISTING 

DO  EMENU1 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue... 
wait^subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  -  2 

*  DO  UPDATE  PRIORITIES 

DO  EMENU2 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

9  23,0  SAY  'Press  any  key  to  continue... 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 
«   DO  PRINT  REPORTS 

DO  EMENU3 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

§  23,0  SAY  'Press  any  key  to  continue... 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  4 

«   DO  ARCHIVE  HISTORICAL  DATA 

DO  EMENU4 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue... 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

*  EOF:  EMENU. PRG 


Program. 


EMEHU1.PRC 


*  Author...:  JOAN  ZIMMERMAN  i    ELBERT  SHAM 

*  Date :  02/16/89 

*  Notice...:  Copyright  (c)  1989,  JOAN  ZIMMERMAN  I  ELBERT 
SHAM,  All  Rights  Reserved 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  EQUIP 

DO  WHILE  .T. 
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*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

«  :,  0  TO  14,  79  DOUBLE 

8    3, 17    SAY     (OFDATE         PPOCUFEMENT         LIST 
I    N   G] 

a    4, 1    TO    4, 78   DOUBLE 

»  display  detail  lines 

8   7,30  SAY  [1.  ADD  EQUIPMENT  INFORMATION] 

8   8,30  SAY  [2.  CHANGE  EQUIPMENT  DATA] 

8   9,30  SAY  [3.  REMOVE  EQUIPMENT  ENTRY) 

8  10,30  SAY  (4.  REVIEW  EQUIPMENT  LIST] 

8  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  aelectnura 

8  14, 33  SAY  "  select 

8    14,42    GET    selectman    PICTURE    "9"    RANGE    0,4 

READ 

DO   CASE 

CASE  selectnura  »  0 
RETURN 

CASE  selectnum  =  1 

*  DO  ADD  INFORMATION 

SET  CONFIRM  OFF 

SET  FORMAT  TO  EMENU1_1 

APPEND  BLANK 

•THIS  COMPUTES  THE  EXTENDED  PRICE 

REPLACE  EXTPRICE  HITH  QTY  *  UNITPRICE 

CLOSE  FORMAT 

•VERITY  THAT  THE  CODE  NUMBER  GIVEN  IS  NOT  A 
DUPLICATE 

•IF  IT  IS,  NOTIFY  USER  AND  ALLOW  THEM  TO  CHANGE  THE 

•NUMBER  WITHOUT  REEDITING  THE  COMPLETE  INFORMATION 

•THEN  REPLACE  THE  OLD  CODE  NUMBER  WITH  THE  NEW 
NUMBER 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  2 

*  DO  CHANGE  INFORMATION 

DO  EMENU1  2 


SET  CONTIRM  OrF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnura  =  3 

*  DO  REMOVE  INFORMATION 

DO  EMENU1_3 
SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  4 

*  DO  REVIEW  INFORMATION 
M_SECT  »  " 

CLEAR 

8  6, 0  TO  8,79  DOUBLE 

8  7,15  SAY  "Enter  the  section  code  of  the  section 
to  review"; 

GET  M_SECT  PICTURE  "XXX" 

READ 

SET  HELP  OFF 

SET  TILTER  TO  SECTCODE«M_SECT 

GO  TOP 

BROWSE  NOAPPEND  NOMENU 

SET  FILTER  TO 

CLEAR  MEMORY 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 
END CASE 

ENDDO  T 

RETURN 

•  EOF :  EMENU1 . PRG 

-Z 


Prog ran . 


EKKNU1  2.PBC 


•  Author...:  JOAN  ZIMMERMAN  i    ELBERT  SHAW 

•  Date :  02/16/89 

•  Notice...!  Copyright  (c)  1989,  JOAN  ZIMMERMAN  4  ELBERT 
SHAW,  All  Rights  Reserved 

SET  TALK  OFT 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  EQUIP 
DO  WHILE  .T. 

•  Display  menu  options,  centered  on  the  screen. 

•  draw   menu    border    and   print    heading 
CLEAR 

8    2,     0    TO    12,79   DOUBLE 

8    3,2  3    SAY     [CHANGE         PROCUREMENT      DATA] 

8  4, 1  TO  4, 78  DOUBLE 

•  display  detail  lines 

8   7,27  SAY  [1.  BY  EQUIPMENT  CODE  NUMBER] 

8   8,27  SAY  [2.  BY  SECTION  CODE] 

8  10,  27  SAY  '0.  EXIT' 

STORE  0  TO  selectnura 

8  12,33  SAY  "  select      " 

e  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE   selectnum   •   0 
RETURN 

CASE    selectnura   -    1 

•  DO  BY  EQUIPMENT  CODE  NUMBER 

CLEAR 

M  EQ  «  0.0 

86,0  TO  8,7  9  DOUBLE 

8  7,15  SAY  "Enter  the  Equipment  Code  Number:"; 

GET  M_EQ  PICTURE  "9999.99" 
READ 
IF  M_EQ  -  0.0 

LOOP 
ENDIT 
GO  TOP 

LOCATE  FOR  EQCODE=M_EQ 
SET  FORMAT  TO  EMENU1_1 
READ 

CLOSE  FORMAT 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

e  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  2 

•  DO  BY  SECTION  CODE 

CLEAR 

M_SECT  =  " 
86,0  TO  8,79  DOUBLE 

87,15  SAY  "Enter  the  Section  Code  for  section 
needing  changes:"; 

GET  M_SECT  PICTURE  "AAA" 
READ 
IF  M_SECT  -  " 

LOOP 
ENDIT 

RECORD  -  " 
GO  TOP 
CLEAR 
LIST  ALL  EQCODE, SECTCODE, PEQDATE, DESCFIPT. PEQTYPE; 

FOR  SECTCODE-M_SECT 
821,10  SAY  "Enter  the  Record  Number  of  the  record; 

to  change:"  GET  RECORD 
READ 

GOTO  I  RECORD 
SET  FORMAT  TO  EMENU1_1 
READ 

CLOSE  FORMAT 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait  subst 
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READ 

SET  CONTIRM  ON 


ENDCASE 


ENDDO  T 

RETURN 

*  EOr:  EMZNU1_2  .  PRO 

"Z 


Program. . : 


■MKMU1  3.  PRO 


«  Author...:  JOAN  ZIMMERMAN  t    ELBERT  SHAW 

*  Date :  02/16/89 

«  Notion...  :  Copyright  (c)  1989,  JOAN  ZIMMERMAN  t  ELBERT 
SHAW,  All  Rights 

set  talk  off 
set  bell  off 
set  status  off 
set  escape  off 
set  contirm  on 
use  equip 
stillatit  -  .t. 
do  while  stillatit 

*  Display  menu  options,  centered  on  the  screen. 

*  drew  nanu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3, 17  SAY  (REMOVE    PROCUREMENT    ENTR 
Y] 

8  4,1  TO  4, 78  DOUBLE 

*  display  datail  linos 

8  7,27  SAY  [1.  BY  EQUIPMENT  CODE  NUMBER] 
e   8,27  SAY  [2.  BY  SECTION  CODE) 

9  10,  27  SAY  '0.  EXIT' 
STORE  0  TO  selectman 

8  12,33  SAY  "  select 

8  12,42  GET  selectnura  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnura  =  0 
RETURN 

CASE  selectnum  -  1 

»   DO  BY  EQUIPMENT  CODE  NUMBER 

ANSWEP  m    ■  " 

CLEAR 

M_EQ  -  0.0 

86, 0  TO  8, 7  9  DOUBLE 

8  7,15  SAY  "Enter  the  Equipment  Code  Number:"; 

GET  M_EQ  PICTURE  "9999.99" 
READ 

**  If  no  number  return  to  menu  ** 
IF  M_EQ  =0.0 

STILLATIT  =  .F. 

LOOP 
ENDIF 

**  Look  for  equipment  code  ** 
LOCATE  FOR  EQCODE=M_EQ 
CLEAR 

DISPLAY  EQCODE, SECTCODE, REQDATE, DESCPIPT, REQTYPE 
? 

WAIT  "REMOVE  THIS  RECORD?  (Y/N) "  TO  ANSWER 
IF  UPPER (ANSWER)  =  "Y" 

DELETE  RECORD  RECNO() 
ENDIF 

SET  TALK  ON 
87,  15 

RECALL  ALL 

WAIT  "This  is  where  the  pack  would  go" 
SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnum  •  2 

»   DO  BY  SECTION  CODE 

ANSWER  -  "  " 

CLEAR 

M_SECT  -  " 

86,0  TO  8,79  DOUBLE 

e7,15  SAY  "Enter  the  Section  Code  for  deletions:"; 

GET  M  SECT  PICTURE  "8  I  AAA" 


READ 

RECOFD  -  " 

GO  TOP 

clear 

LIJT  ALL  EQCODE,  SECTCODE.  RFOPATE,  DES'-PIPT,  TTOTVt  r  ; 

FOR  SECTCODE-M_SECT 
821,10  SAY  "Enter  the  Record  Number  of  the  record; 

to  remove:"  GET  RECORD 
READ 

GOTO  (RECORD 
CLEAR 

DISPLAY  EQCODE, SECTCODE, REQDATE, DESCRIPT,  REQTYPE 
? 

WAIT  "REMOVE  THIS  RECORD?  (Y/N)"  TO  ANSWER 
IF  UPPER (ANSWER)  -  "Y" 

DELETE  RECORD  RECNO() 
ENDIF 

SET  TALK  ON 
8  7,15 
RECALL  ALL 

WAIT  "This  is  where  the  pack  would  go  " 
SET  TALK  orF 
READ 

CLOSE  FORMAT 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 


ENDDO  T 

RETURN 

*  EOT:  EMENU1  2 .  PRG 


mmm 


Program. 


1XRKU2  .  PRC 


Author .  . 
Date. . . , 
Notice. . 


JOAN  ZIMMERMAN  s  ELBEPT  SHAW 

02/17/89 

Copyright   (c)   1989,   JOAN  ZIMMERMAN  C  ELBEPT 
SHAM,  All  Rights  Reserved 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 

set  escape  orr 

SET  CONFIRM  ON 
USE  EQUIP 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,  17  SAY  [UPDATE    PRIORITIES/STATU 
S) 

8  4, 1  TO  4, 78  DOUBLE 

*  display  detail  lines 

8   7,32  SAY  [1.  UPDATE  PRIORITIES) 
8   8,32  SAY  [2.  UPDATE  STATUS] 
8  10,  32  SAY  '0.  EXIT- 
STORE  0  TO  selectnum 
8  12, 33  SAY  "  select      " 

e  12,42  GET  selectnura  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE    selectnura    »    0 
RETURN 

CASE    selectnum    =    1 

♦  PC    ntp»TF    TPT^FITIES 

DO    EMENU2_1 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_sutos"t 

READ 

SET  CONFIPM  ON 

CASE  selectnum  =  2 

*  DO  UPDATE  STATUS 

DO  EMENU2  2 
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SET  CONFIRM  OFF 

STORE  '  '  TO  walt_subst 

8  23,0  SAY  'Puss  any  key  to  continue. 

READ 

SET  CONFIRM  ON 


ENDCASE 


ENDDO  T 

RETURN 

*  EOF:  EMINU2.PRG 

*Z 


Program. 


UH]fU2  l.FRC 


«  Author...:  JOAN  ZIMMERMAN  I    ELBERT  SHAM 

•  Date :  02/16/89 

»  Notice...:  Copyright  (c)  1989,  JOAN  ZIMMERMAN  I    ELBERT 
SRAH,  All  Rights  Reserved 

set  talk  orr 

SET  BELL  OrF 
SET  STATUS  OFF 

set  escape  orr 

SET  CONFIRM  ON 
USE  EQUIP 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

§  2,  0  TO  14, 79  DOUBLE 

8  3,24    SAY     [UPDATE         PRIORITIES) 

8  4,1    TO    4,78   DOUBLE 

*  display  detail  lines 

8   7,31  SAY  [1.  MEDCASE  EQUIPMENT] 

8   8,31  SAY  [2.  CEEP  EQUIPMENT] 

8   9,31  SAY  [3.  CAPR  EQUIPMENT] 

§  10,31  SAY  (4.  OTHER  EQUIPMENTJ 

8  12,  31  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  14,33  SAY  "  select 

8  14,42  OET  selectnum  PICTURE 

READ 


RANGE  0, 4 


DO  CASE 

CASE  selectnum  -  0 
RXTURN 

CASE  selectnum  •=  1 

*  DO  MEDCASE  EQUIPMENT 
CLEAR 

SET  FILTER  TO  REQTYFE-"MEDC" 
GO  TOP 

BROWSE  FIELDS 
EQCODE, REQTYPE, SECTCODE, DESCRIPT,  URGCODE,  PRIORITY, 

QTY,UNITPRICE 
SET  FILTER  TO 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  2 

*  DO  CEEP  EQUIPMENT 

CLEAR 

SET  FILTER  TO  REQTYPE="CEEP" 
GO  TOP 

BROWSE  TIELDS 
EQCODE, REQTYPE, SECTCODE, DESCRIPT, URGCODE, 
PRIORITY, QTY, UNITPRICE 
SET  FILTER  TO 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  3 

*  DO  CAPR  EQUIPMENT 

CLEAR 

SET  FILTER  TO  REQTYFE»"CAPR" 

GO  TOP 

BROWSE  FIELDS 


EQCODE, REQTYPE, SECTCODE, DESCRIPT, URGCODE, 

PRIORITY, QTY, UNITPRICE 
SET  FILTER  TO 

SET  CONTIRM  OrF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SIT  CONTIRM  ON 

CASE  selectnum  =  4 

»   DO  OTHER  EQUIPMENT 

CLEAR 

SET  FILTER  TO  RIQTYPE-"OTHE" 

GO  TOP 

BROWSE  FIELDS 

EQCODE, REQTYPE, SECTCODE, DESCRIPT, URGCODE, 

PRIORITY, QTY, UNITPRICE 
SET  FILTER  TO 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
vait_subst 

READ 

SET   CONFIRM   ON 
ENDCASE 

ENDDO   T 

RETURN 

»    EOr:     EMENU2.PRG 


Program. 


■MEJTO2    2. PPG 


Author . . 
Date. . . , 
Notice.  , 


JOAN  ZIMMERMAN  (  ELBERT  SHAW 
02/17/89 

Copyright  (c)  1989,  JOAN  ZIMMERMAN  i  ELBERT 
SHAW,  All  Rights  reserved 

set  talk  orr 

SET  BELL  OFF 

SET  STATUS  OFF 

SET  ESCAPE  OFF 

SET  CONFIRM  ON 

USE  EQUIP 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

§  2,  0  TO  12, 79  DOUBLE 

8  3,  28    SAY    [UPDATE         STATUS] 

8  4,1    TO    4,78   DOUBLE 

*  display  detail  lines 

8   7,31  SAY  [1.  BY  EQUIPMENT  CODE] 
8   8,31  SAY  [2.  BY  SECTION  CODE] 
8  10,  31  SAY  '0.  EXIT- 
STORE  0  TO  selectnum 
e  12, 33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE    selectnum   -    0 
RXTURN 

CASE    selectnum    =    1 
*       DO    BY    EQUIPMENT    CODE 

CLEAR 

M_EQ    =    0.0 

86,0    TO    e,79    DOUBLE 

8    7,15   SAY    "Ent«*r   the   Equipment    Code  Number:"; 

GET   !I_EQ    FICT'TE    "9999. «?" 
READ 
IF   M_EQ    -    0.0 

LOOP 
ENDIF 
GO  TOP 

LOCATE  FOR  EQCODE-M_EQ 
SET  FORMAT  TO  EMENU2_2 
READ 

CLOSE  FORMAT 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 
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SET  CONTIRM  ON 


CASE  selectnuro  *  2 

■   DO  Di  SECTION  CPE 


update 


CLEAR 

M_SECT  =  " 

86,0  TO  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Section  Code  for  STATUS 


GET  M_SECT  PICTURE  "AAA" 
READ 
IF  M_SECT  -  " 

LOOP 
ENDIT 

RECORD    -    " 
00    TOP 
CLEAR 
LIST   AXL 
EQCODE.SECTCODE, REQDATE, DESCRIPT,  REQTYPE, STATUS; 
TOR    SECTCODE-M_SECT 
821,10    SAY    "Enter   the    Record  Number    for    STATUS 
updates : ■ ; 

OET    RECORD 
READ 

GOTO    i RECORD 
SET    roRMAT    TO    EMENU2_2 
READ 
CLOSE    rORMAT 

SET    CONFIRM  OFF 

STORE    '     '    TO   waitsubst 

8    23,0   SAY    'Press   any    key   to   continue...'    GET 
wait_subst 

READ 

SET    CONFIRM    ON 
ENDTASE 

ENTDO   T 

RETURN 

•    K>F:    EMENU2    2  .  PRG 


Program. 


EMKNU3.PRC 


»    author...:     JOAN    ZIMMERMAN    i    ELBERT    SHAW 

*  rate :    02/16/89 

*  fetice...:    Copyright    (c)    1989,    JOAN    ZIMMERMAN   t    ELBEPT 
SIM,    All    Rights    Reserved 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS    OFF 

set  escape  orr 

SES  CONFIRM  ON 


DO'UfllLE     .T. 

* Display 

*  draw   roe 
TLEAF 
«   2,    0    TO    15 

*  3,28    SAY     [ 
t    4,1    TO    4,7 

* display 

I  7,27  SAY 
9  8,27  SAY 
4      9,27    SAY 

*  10,27  SAY 
J  11,27  SAY 
»  13,  27  SAY 
STORE  0  TO  ! 
*•  15,33  SAY 
I  15,42  GET 
READ 


menu  options,  centered  on  the  screen, 
nu  border  and  print  heading 

, 7  9  DOUBLE 

PRINT         REPORTS] 

8   DOUBLE 

detail  lines 
[1.  DEPARTMENT  REPORTS) 
[2.  EQUIPMENT  TYFE  REPORTS] 
[3.  PRIORITY  WORKSHEETS] 
[4.  HISTORICAL  FILE  REPORTS] 
[5.  EXPORT  FILES  TO  SPREADSHEET] 

'0.  EXIT' 
electnuni 
"  select      " 
selectman  PICTURE  "9"  RANGE  0,5 


SO   CASE 

CASE    selectnuro    =    0 
RETURN 

CASE    selectnuro    •    1 

*      DO    DEPARTMENT    REPORTS 

DO    EMENU3_1 

SET    CONFIRM   OFF 
STORE    '     '     TO   wait_subst 
8    23,0    SAY    'Press    any    key    to    continue 
waitsubst 

READ 

SET   CONFIRM   ON 


CASE   selectnuro  -    2 

*  DO  CATEGORY /STATUS  REPORTS 
DO  EMENU3_2 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET   CONFIRM   ON 

CASE   selectnuro  *    3 

*  DO  PRIORITY  WORKSHEET  REPORT 

DO  EMENU3_3 
SET  CONFIRM  OrF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnuro  ■»  4 

*  DO  HISTORICAL  TILE  REPORTS 
DO  EMENU3_4 

SET  CONFIRM  OrF 
STORE  '  '  TO  wait_subst 
8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET   CONTIRM   ON 


CASE  selectnuro   -    5 
*      DO   EXPORT   TO    FILE 


DO    EMENU3    5 


SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_«ubst 

READ 

SET    CONFIRM    ON 
ENDCASE 

ENDDO    T 

RETURN 

»     EOF:     EMENU3.PRG 

"Z 


Program. . 


Author. . 
Date. . . . 
Hotice. . 


EMEKU3_  1  .  PRC 

JOAN  ZIMMERMAN  s  ELBEPT  SHAW 

02/17/89 

Copyright   <C)  1989,   JOAN  ZIMMERMAN  s  ELBEPT 


SHAW,  All  Rights  Reserved 

SET  rjLLK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  E0UIP 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  13, 79  DOUBLE 

8    3,23    SAY     [DEPARTMENT         REPORTS] 

8    4,1    TO    4,  78   DOUBLE 

* display  detail  lines 

8   7, 32  SAY  [1.  BY  COST] 

8   8,32  SAY  [2.  BY  URGENCY) 

8   9,32  SAY  (3.  BY  STATUS  CODE) 

8  11,  32  SAY  '0.  EXIT' 

STORE    0    TO    selectnuro 

8    13,33    SAY    "    select 

8    13,42    GET    selectnuro    PICTURE    "9"    PANGE    0,3 

READ 

DO    CASE 

CASE   selectnuro   ■   0 
RETURN 

CASE    selectnuro    ■    1 
*       DO    BY    COST 


Set    index   to    coat    fort    and   Print    report   here 


225 


SET  CONFIRM  OFF 
STOFE  '    TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue.. 
wait_aubst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  «>  2 
*   DO  BY  URGENCY 


Set  in«1+x  to  urgency  sort,  print  report 


here  »»•*« 


SET  CONFIRM  OrF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_aubst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  *  3 
•   DO  BY  STATUS  CODE 

*****  get  inA+T   to  statu*  code  fort,  print  report 
bare  ***** 

SET  CONTIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  tcey  to  continue...'  GET 
wait_subst 

READ 

SET    CONFIRM   ON 
END  CASE 

ENDDO    T 

RETURN 

*    EOF  :     EMENU3_1  .  PRO 

AZ 


warn 


*    Program. 


EMENTJ3    2.PP.C 


JOAN  ZIMMERMAN  s  ELBERT  SHAW 

02/17/89 

Copyright  (c)  1989,  JOAN  ZIMMERMAN  I  ELBERT 


*  Author. . . 

*  Date 

*  Notice. . . 
SHAW,  All  Rights 

*  Reserved 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  EQUIP 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8  3,15    SAY     [PROCUREMENT         TYPE  REPOR 

T    S] 

8  4,1    TO    4,78   DOUBLE 

*  display  detail  lines 

8   7,32  SAY  [1.  MEDCASE  EQUIPMENT) 

8   8,32  SAY  [2.  CEEP  EQUIPMENT] 

8   9,32  SAY  [3.  CAPR  EQUIPMENT] 

8  10, 32  SAY  [4.  OTHER] 

8  12,  32  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  selectnum  »  0 
RETURN 

CASE  selectnum  •*  1 

*   DO  MEDCASE  EQUIPMENT 


*   Call  Sorting  program,  sort  by  priority  or  cost 

DO  EM3_2_1 
*****   print  MEDCASE  Equipment  report  here  •«««* 

SET  CONFIRM  OFF 


STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Prews  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  C» 

CASE  selectnum  «  2 
«   DO  CEEP  EQUI 


Call  Sorting  program,  »ort  by  priority  or  cost 
DO  EM3  2  1 


***** 


Print  CETJ*  ■kfuipaant   report  hare 


SET   CONFIRM  c  *T 
STORE    '     '     TO    «ait_subst 

8    23,0   SAY    'Press    any   key  to   continue...'    GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 

*  DO  CAPR  EQUIPMSBT 

*  Call  Sorting  program,  sort  by  priority  or  cost 
DO  EM3_2_1 

*****   print  CAPR  equipment  report  hare  ***** 

SET  CONTIRM  C/T 
STORE  '  '  TO  »ad.t_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  OH 

CASE  selectnum  »  4V 

*  DO  OTHER 


*   Call  Sorting  program,  sort  by  priority  or  cost  * 
DO  EM3_2_1 

*****   print  OTHER  Equipment  report  here  ***** 

SET  CONFIRM  OfF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  ' Fress  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  OH 


ENDDO  T 

RETURN 

*  EOF:  EMENU3_2.PRG 

*Z 


*  Program. . : 

EH3_2_1.PEG 

»  Author...:  JOAN  ZIMMERMAN  4  ELBERT  SHAM 

*  Date :  02/17/89 

*  Notice...:  Copyright  <c)  1989,  JOAN  ZIMMERMAN  f.    ELBERT 
SHAH,  All  Rights  Reserved 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  bolder  and  print  heading 
CLEAP 

6  2,  0  TO  12, 79  DOUBLE 

8    3,15    SAY     [CHOOSE         DESIRED         SORT         OPT 
ION] 

8    4,1    TO    4, 78   DOUBLE 

*  display  detail  lines 

6   7,33  SAY  [1.  SORT  BY  PRIORITY] 
8   8,33  SAY  [2.  SORT  BY  COST] 
8  10,  33  SAY  '0.  EXIT' 
STORE  0  TO  selectnum 
8  12, 33  SAY  "  select 


226 


8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE  selectnum  -  0 
RETURN 

CASE  selectnum  ■  1 

•   DO  SORT  BY  PRIORITY 

******   get  index**  her*  to  «ort  by  priority 


SET  CONTIRM  OFr 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_aobst 

READ 
RETURN 

CASE  selectnum  =  2 
*   DO  SORT  BY  COST 


Set  indexes  h*r«  to  fort  by  coat 


SET  CONFIRM  OFF 

STORE  '  '  TO  uait_subst 

8  23,0  SAY  'Press  any  key  to  continue.. 
weit_subst 

READ 

RETURN 
ENDCASE 

ENDDO  T 

RETURN 

•  EOr  :  BM3_2_1  .  PRO 

-z 


Program. 


BMSIfU3    3.PRG 


*  Author...:  JOAN  ZIMMERMAN  t    ELBEPT  SHAM 

*  Date !  02/17/89 

*  Notice...:  Copyright  (c)  1989,  JOAN  ZIMMERMAN  t    ELBEPT 
SRAM,  All  Rights  Reserved 

SET  TALK  OFF 

set  bell  orr 

SET  STATUS  OFF 

set  escape  orr 

SET  CONFIRM  ON 
USE  EQUIP 

*****  Set  cost  sort,  highest  to  lowest  ***** 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8  3,17    SAY     [PRIORITY         WORKSHEET         FORM 
S] 

8  4,1    TO    4,7  8    DOUBLE 

*  display  detail  lines 

8   7,29  SAY  [1.  MEDCASE  PRIORITY  FORM] 

8   8,29  SAY  [2.  CEEP  PRIORITY  FORM] 

e   9,29  SAY  [3.  CAPR  PRIORITY  FORM] 

8  10,2  9  SAY  [4.  OTHER  PRIORITY  FORM] 

8  12,  29  SAY  '0.  EXIT' 

STORE   0    TO    selectnum 

e  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  =  1 

*  DO   MEDCASE    PRIORITY    TORM 

*  RIFOPT    FORM   BM3    3    FOR    P_E2TYPE=MXDC    TO   PRINT 


SET    CONFIRM    OFF 
STORE    '     '     TO   wait_subst 
8    23,0    SAY    'Press    any    key   to   continue 
wait_subst 

READ 


SET    CONFIRM   ON 


CASE    selectnum    -    2 

*       DO   rp.cr    tpinpiTY    FORM 


•      REPOPT    FORK   «M3    3    ALL    FOR    R*QTYPB»aKP    TO   PRINT 


SET    CONFIRM   OFF 
STORE    '     '     TO   wait_subst 

e    23,0   SAY    'Press   any   key   to   continue...'    GET 
wait_subst 

READ 

SET    CONFIRM  ON 

CASE    selectnum    «    3 

«       DO    CAPR    PRIORITY    FORM 

•  REPORT   FORM   BM3_3   ALL    FOR    RBQTYTsXAPR    TO   PRINT 

SET   CONFIRM   OFF 
STORE    '     '     TO    wait_subst 

8    23,0    SAY    'Press    any    key   to    continue...'    GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■■  4 

•  DO   OTHER    PRIORITY    FORM 

•  RIPOPT    FORM   KM3_3   ALL    FOR    RE0TYPE=OTRX    TO   PRINT 

SET    CONFIRM    OFF 

STORE    '     '     TO   walt_subst 

8    23,0    SAY    'Press    any    key   to   continue...'    GIT 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

*  EOF:  EMENU3_3.PRG 

*Z 


Program. 


uatru3  4 .  prs 


*  Author...:  JOAN  ZIMMEPMAN  4  ELBERT  SHAM 

«  Date :  02/17/89 

«  Notice...:  Copyright  (c)  1989,  JOAN  ZIMMERMAN  i    ELBEPT 

SHAM,  All  Rights  Reserved 

SET  TALK  OFF 

SET  BELL  OFF 

SET  STATUS  OFF 

SET  ESCAPE  OFF 

SET  CONFIRM  ON 

USE  EQHIST 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12, 79  DOUBLE 

8  3,23    SAY     [HISTORICAL         REPORTS] 

8  4,1    TO    4,78    DOUBLE 

*  display  detail  lines 

8   7,27  SAY  [1.  PRINT  HISTORICAL  DATA  REPOPTSJ 

e   8,27  SAY  [2.  PRINT  HISTORICAL  SUMMARY] 

8  10,  27  SAY  '0.  EXIT' 

STORE    0   TO   selectnum 

e    12,33    SAY    "    select 

e    12,42    GET    selectnum    PICTURE    "9"    RANGE    0,2 

READ 

DO   CASE 

CA::'E  relectnum  =  0 
RETURN 

CASE  selectnum  ■  1 
*   DO  PRINT  ALL  HISTORICAL  DATA 
DO  EM3_4_1 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIPM  ON 

CASE  selectnum  =  2 
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*  DO  PRINT  HISTORICAL  SUMMARY 

*  THE  HISTORICAL  SUMMARY  ROUTINE  TAKES  THE  HISTORICAL 

n  i.e 

*  AND  COMPUTES  THE  FOLLOMING  INFORMATION 

*  THE  TOTAL  NUMBER  OF  REQUESTS  BY  TYPE 

*  THE  AVERAGE  COST  PEP  TYPE 

*  THE  AVERAGE  TIME  TO  COMPLETE  THE  ACTION  BASED 
ON       THE 

«         DURATION  INFORMATION  COMPUTED  UPON  ARCHIVING 

*  THE  NUMBER  OF  REQUESTS  BY  SECTION,  THEN  TYPE 

*  THE  AVERAGE  COST  BY  SECTION,  THEN  TYPE 

*  PRINT  HISTORICAL  SUMMARY  REPORT  HERE 

SET  CONFIRM  OFF 

STORE  '  '  TO  «ait_subst 

8  23,0  SAY  'Ptbss  any  Key  to  continue...'  GET 
wait_subst 

READ 

SET    CONFIRM   ON 
END CASE 

ENDDO    T 

RETURN 

•    EOr:     EMENU3_4.PRG 


Program. 


EM3  4  l.PRG 


JOAN  ZIMMERMAN  s  ELBERT  SHAM 

02/17/89 

Copyright  (c)  1969,  JOAN  ZIMMERMAN  i.    ELBERT 


*  Author. . . 

*  Date 

*  Notice.  .  . 
SHAM,  All  Rights 

*  Reserved 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

*  Get  desired  earliest  month  of  report 
CLEAR 

M_DATE  -    " 

§?, 0  TO  8, 7  9  DOUBLE 

8  7,10  SAY  "Enter  the  earliest  Month  and  Year  for  historical 

report :  "; 

GET  M_DATE  PICTURE  "XX/XX" 
READ 
IF  M_DATE  «  "  " 

LOOP 
ENDIF 
DO  MHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

'     draw  menu  border  and  print  heading 

CLEAR 

8    2,     0    TO    13,79    DOUBLE 

8    3,23    SAY     [HISTORICAL         REPORTS) 

8    4,1    TO    4,78   DOUBLE 

*  display  detail  lines 

8   7,33  SAY  [1,  BY  SECTION) 
8   8,33  SAY  [2.  BY  EQUIPMENT  TYPE) 
8  11,  33  SAY  '0.  EXIT- 
STORE  0  TO  selectnum 
8  13,33  SAY  "  select 

8  13,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 
READ 

DO  CASE 

CASE  selectnum  -  0 
RETURN 

CASE  selectnum  ■  1 
*   DO  BY  SECTION 

*****   Set  indexes  here  for  sections  ***** 


Print  Historical  report  by  Section  ha 


SET  CONTIRM  OFF 
STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  2 
*   DO  BY  CATEGORY 


*****   Set  indexes  here  for  Equipment  type  ***** 
*****   Print  Historical  report  by  Equipment  Type  h*ra 


SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 

wait  subst 


READ 

SET  CONTIRM  ON 


ENDCASE 


ENDDO  T 

RETURN 

*  EOF:  EM3_4_1.PRG 

"Z 


*  Program. .  : 

EMENU3_5  .  PRO 

*  Author...:  JOAN  ZIMMERMAN  t  ELBERT  SHAM 

*  Date :  02/17/89 

*  Notice...:  Copyright  (c)  1989,  JOAN  ZIMMERMAN  t  ELBERT 
SHAM,  All  Rights  Reserved 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONTIRM  ON 

DO  MHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw   menu   border    and   print    heading 
CLEAR 

8    2,     0    TO    12,79    DOUBLE 

8    3,14    SAY     [EXPORT         FILES         TO         SPREADS 
H    E    E    T) 

8    4,  1    TO    4,78   DOUBLE 

*  display  detail  lines 

8   7,26  SAY  [1.  EXPORT  CURRENT  DATABASE] 

8   8,26  SAY  [2.  EXPORT  HISTORICAL  DATABASE] 

8  10,  26  SAY  *0.  EXIT' 

STORE  0  TO  selectnum 

e  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  =  1 

«   DO  EXPORT  CURRENT  DATABASE 

USE  EQUIP 

•*•••   Mr it*  CURRENT  DATABASE  export  program  hare 


CLOSE  ALL 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnum  ■  2 

«   DO  EXPORT  HISTORICAL  DATABASE 

USE  EQHIST 

*****   Mrit*  HISTORICAL  DATABASE  export  program 
here  »««•• 

CLOSE  ALL 

SET  CONTIRM  OTF 

STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 
ENDCASE 

ENDDO  T 
RETURN 
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EOF:  EMENU3  5.  PRO 


*    Program.  .  : 


■MMIU4.PRC 


*  Author.  .  . 

*  Date 

*  Notice .  .  . 


JOAN  ZIMMERMAN  s  ELBERT  SHAH 

02/16/89 

Copyright  (c)  1989,  JOAN  ZIMMERMAN  s  ELBERT 
SRAM,  All  Rights  Reserved 
«  Notes . . . . : 


set  talk  orr 

SET  BELL  OFF 
SET  STATUS  OFr 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 


*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

ANSWER  -  "  " 

8    4,    0    TO    16,79    DOUBLE 

8  5,15    SAY     [ARCHIVE  TO  HISTORICAL  F 
I    L    E] 

9  6,1    TO    6,78    DOUBLE 

8  8,15  SAY  "CAUTION:   All  files  with  a  received  status, 
RC,  will  be" 

6  9,25  SAY  "removed  from  the  equipment  listing" 

8  10,25  SAY  "to  the  historical  file." 

8  14,25  SAY  "Do  you  wish  to  continue  the  archive?  (Y/N)"; 

GET  ANSWER  PICTURE  "!A" 
READ 
IF  ANSWER  «  "Y" 

RETURN 
ELSE 

8  18,15  SAY  "*«**  Program  to  Archive  rile  **«»" 

*  THE  PROGRAM  SEARCHES  THE  ACTIVE  FILE  FOP.  STATUS 
CODES         -  RC 

»  IF  FOUND  IT  TRANSFERS  THE  NECESSARY  FIELDS  TO  THE 
HISTORICAL 

*  FILE  AND  COMPUTES  THE  DURATION  IN  DAYS  BETWEEN  THE 
REQUEST 

*  DATE  AND  CURRENT  SYSTEM  DATE.  THE  SYSTEM  DATE  IS 
ALSO         INSERTED 

*  INTO  THE  HISTORICAL  DATABASE  RECORD  ALON  WITH  THE 
COMPUTED 

*  DURATION. 
ENDIF 

WAIT  "Press  any  key  to  continue  ..." 

SET  STATUS  ON 

SET  TALK  ON 

CLEAR  ALL 

RETURN 


RETURN 

»  EOF:  KMENU4.PRG 
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APPENDIX  E.   PERSONNEL  PROGRAMS 


TABLE  OF  PROGRAMS 


PMENU.PRG 
PMENU1 . PRG 
PMENU2  .  PRO 
PMENU3.PRG 
PMENU4.PRG 
PMENU4_1  .  PRG 
PMENU4_2 . PRG 
PMENU4_3 .  PRG 
PMENU4_4 . PRG 
PMENU5  .  PRG 
PMENU6.PRG 


DISCLAIMER 

The  purpose   of  this  programming   code   is   to 
facilitate   the   understanding   of  the 
requirements  presented  in    Chapter   5  of  this 
thesis.       The   nature   of  this  project  precludes 
it   actual    Implementation   in   DBASE   III+.    To 
fully   implement    the   requirements    the    system 
designer   will    need   a    full    range    of  capabilities 
that    does   not    currently   exist    in   DBASE   III+. 

DBASE   III+    served   as    the   modeling    tool    by 
which    the   screens   were   generated  and  where 
necessary,    specific   code   was   written    to 
illustrate  a  point.    The   actual    working   code 
merely   acts   as   a   shell    in    which    to   run   the 
menus.    A   close   analysis   of  the  program   code   can 
facilitate  implementation   in   a  more   suitable 
language,    i.e.,    PARADOX,    which    can    support    the 
graphics   and  high   level    relationships   involved 
in    the   various   databases .    Where   the   actual 
requirements  process  may  appear   to  be   unclear, 
comments    were   added   within    the    code    to    explain 
these    areas    to    the    designer . 


Program: 


PMEKTt.PRC 


ELBERT  T.  SHAW  (.    JOAN  ZIMMERMAN 
02/02/89 

Copyright (c) 1989,  E.  T.  SHAM  i    JOAN  ZIMMERMAN,  All 
Notes .... :Main  Menu  for  the  Personnel 


*  Author. 

*  Date. . . 

*  Notice. 
Rights  Reserved 
System 

SET  TALK  OFF 
SET  BELL  OrF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

§  2,  0  TO  16,79  DOUBLE 

8  3,15  SAY  [DEPAPTMENT  OF  FAMILY  PPACTICE  PERSONNEL 
SYSTEMI 

!  4,1  TO  4,18  DOUBLE 

*  display  detail  lines 

8   7,22  SAY  [1.  Update  Personnel  Listing] 

8   8,22  SAY  [2.  Update  TDA  Listing] 

8   9,22  SAY  [3.  Quick  Update  from  RIR  Report] 

8  10,22  SAY  [4.  Update  CME  Listing/Budget  J 

8  11,22  SAY  [5.  Update  Leave  and  Absence  Listings] 

§  12,22  SAY  [6.  Print  Reports] 

§  14,  2  2  SAY  [0.  EXIT] 

selectnuro  =  0 

8  16, 33  SAY  "  select 

8    16,42    GET    selectnuro    PICTURE    "9"    RANGE    0,6 

READ 

DO  CASE 


CASE  selectnuro  -  0 
CLEAR  ALL 
RETURN 

CASE  selectnuro  -  1 

*  DO  Update  Personnel  Listing 

DO  PMENU1 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 
8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnuro  •  2 

*  DO  Update  TDA  Listing 

DO  PMENU2 

SET  CONFIRM  OrF 
STORE  '  '  TO  wait_subst 
8  23,0  SAY  'Press  any  key  to  continue. 
vait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnuro  -  3 

*  DO  Quick  Update  from  RIR  Report 

DO  PMENU3 

SET  CONTIRM  OFF 
STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  4 

*  DO  Update  CME  Listing/Budget 

DO  PMENU4 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnuro  ■  5 

*  DO  Update  Leave  and  Absence  Listings 

DO  PMENU5 

SET  CONTIRM  OFF 
STORE  '  '  TO  wait_subst 
8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET    CONTIRM   ON 

CASE    selectnuro   ■    6 

*  DO   Print   Reports 

DO    PMENU6 

SET  CONFIRM  OFF 

STOFE  •  '  I.  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

*  EOF:  PMENU.PPG 

"Z 
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*  Program: 

FMKXUl.FRC 

*  Author. :  ELBERT  T.  SHAM  i    JOAN  ZIMMERMAN 
«  Date. . . :  02/02/89 

»  Notice. :Copyright (c>  1989,  E.  T.  SHAM  4  JOAN  ZIMMERMAN, 
All  Rights  Reserved 

*  Notes  .... :UPDATE  PERSONNEL  LISTING 
SET  TALK  OFF 

SET  BELL  orr 

set  escape  orr 

SET  CONFIRM  ON 

SELECT  A 

USE  TDA  INDEX  TDA 

SELECT  B 

USE  PERSON  INDEX  p_TDA 

SELECT  A 

JOIN   WITH    B    TO    TEMP    FOR    TDA_PARA=b->TDA_PARA    .AND.     ; 

TDA_LINE-b->TDA_LINE     .AND.     TDA_POSN-B->TDA_POSN 

CLOSE  ALL 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

6  2,  0  TO  14,79  DOUBLE 

8  3, 17  SAY  [UPDATE    PERSONNEL    LIST 


01 


8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,30  SAY  [1.  ADD  DEPARTMENT  PERSONNEL] 

CHANGE  INFORMATION  ON  A  PERSON] 
DELETE  PERSON  FROM  LISTING) 
REVIEW  ALL  DEPARTMENT  PERSONNEL 


RANGE  0,4 


8   8,30  SAY  [2. 
8   9,30  SAY  [3. 
8  10,30  SAY  [4. 
INFORMATION] 

8  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE 

READ 

DO  CASE 

CASE  selectnum  =  0 
CLEAR  ALL 
RETURN 


CASE  selectnum  =  1 

•   DO  ADD  INFORMATION 

Adding  =  .T. 

DO  WHILE  Adding 

CLEAR 

M_TDAFARA  =  0 
M_TD ALINE  ■  0 
MJTDAPOSN  -  0 
M_code  ■=  SPACE  (5) 
e  6,0  TO  10,79  DOUBLE 

8  7,10  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU 
TO      ADD:"  GET  M_CODE  PICTURE  "19999" 

8  8,10  SAY  "or  Press  Return  to  QUIT" 
READ 

IF  M_CODE  =  "   " 

Adding  =  .F. 

LOOP 
ENDIF 

USE  PERSON 
GO  TOP 

LOCATE  FOR  IDCODE=Tn_code 
IF  FOUND() 

CLEAR 

MESSAGE  -  "ID  CODE  REQUESTED  IS  ALREADY  USED 
B  PERSON  SHOWN  BELOW!" 

SET  FORMAT  TO  CONFIRM 

READ 

CLOSE  TORMAT 

LOOP 
ELSE 

TRY  »  .T. 

DO  WHILE  TRY 

M_TDAPARA  -  0 

CLEAR 

SET  FORMAT  TO  TDAINPUT 

READ 

CLOSE  FORMAT 

USE  TDA 

GO  TOP 

LOCATE    FOP    TDA_PAPA=MTDAPARA    .AND. 
TDA_LINE-M_TDALINE     .AND.     TDA_POSN-M_TDAPOSN 

IT    FOUND  () 

SET  FORMAT  TO  POSITION 

READ 

CLOSE  FORMAT 

ELSE 


8  12,0  TO  14,79  DOUBLE 

8  13,5  SAY  "TDA  POSITION  NOT  AUTHORISED, 


PRESS 


PETURN  TO  TRY  AGAIN. . . " 

WAIT  "  " 

LOOP 
ENDIF 

USE  PERSON 
GO  TOP 

LOCATE    FOR    TDA_PARA=M_TDAPAFA     .AND. 
TDA_LINE-M_TDALINE     .AND.     TDA_POSN-M_TDAPOSN 
IF    FOUND!) 

CLEAR 

SET    FORMAT    TO    OCCUPIED 

READ 

CLOSE  FORMAT 

8  15,0 

SET  FORMAT  TO  CHOICE 

READ 

DO  CASE 

CASE    ANSWER-1 

REPLACE    TDA_POSN    WITH    99 
SET    FORMAT    TO    PERSON 
APPEND    BLANK 
REPLACE    IDCODE    WITH   M_CODE, ; 

TDA_PARA    WITH    M_TDAPARA, 

TDA_LINE    WITH    MJTDALINE, 

TDA_POSN   WITH    MJTDAPOSN 
READ 

CLOSE    FORMAT 
TRY    -    .F. 
LOOP 

CASE    ANSWER-2 

SET    FORMAT    TO    PEPSON 

APPEND    BLANK 

REPLACE    IDCODE    WITH    M_CODE, ; 

TDA_PARA   WITH    M_TDAPAPA, 

TDA_LINE    WITH    MJTDALINE, 

TDA_POSN   WITH    99 
READ 

CLOSE    FORMAT 
TRY    ■=     .F. 
LOOP 

CASE    ANSWER-3 
LOOP 

ENDCASE 
ELSE 

SET    TORMAT   TO    PERSON 

APPEND    BLANK 

REPLACE    IDCODE    WITH   M_CODE, ; 

TDA_PARA   WITH    MTDAPARA,     ; 
TDA_LINE    WITH    MJTDALINE,     ; 
TDA_POSN   WITH    MJTDAPOSN 
READ 

CLOSE    FORMAT 
TRY    -    .F. 
ENDIF 

ENDDO 

ENDIF 

YESNO    ■    "    " 

8    6,0    TO    8,79   DOUBLE 

8    7,15    SAY    "DO   YOU   WISH    TO    ENTER    SOCIAL    ROSTER 

INFORMATION"    GET    YESNO    PICTURE    "!" 

READ 

IF    YESNO    -    "Y" 

*  SET  FORMAT  TO  PRIVATE 

*  APPEND  BLANK 

*  REPLACE  IDCODE  WITH  M_IDCODE 

*  CLOSE  FORMAT 
•ENDIF 

•ENDDO  (ADDING) 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■=  2 

*   DO  CHANGE  INFORMATION 

*  SEEK  M_CODE 

*  IF  BLANK,  EXIT 

*  IF  FOUND!) 

*  SET  FORMAT  TO  PERSON 

*  CHECK  TO  INSURE  POSITION  IS  NOT  OCCUPIED  BY 
SOMEONE  •    IF  OCCUPIED 
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»        SET  FORMAT  TO  CHOICE 
«        GET  CHOICE  AND  EXECUTE  PEP  ADDING 
INSTRUCTIONS 

'    ENPTF 

•ELSE  (i.e.  NOT  FOUND) 

*  NOTIFY  USER  ID  NOT  FOUND,  GIVE  OPTION  TO  SEARCH 
BY        LAST  NAME 

»    SEEK  LAST  NAME 

*  DISPLAY  ALL  WITH  THIS  LAST  NAME,   FIRST  NAME  AND 
ID        CODE 

*  GIVE  USER  OPTION  TO  CHOSE  WHICH  RECORD  NUMBER 

*  USER  PICKS  RECORD  NUMBER 

*  GOTO  RECORD  SELECTED 

*  SET  FORMAT  TO  PERSON 

»    CHECK  TO  INSURE  POSITION  IS  NOT  OCCUPIED  BY 
SOMEONE  *    IF  OCCUPIED 

*  SET  rORMAT  TO  CHOICE 

*  GET  CHOICE  AND  EXECUTE  PER  ADDING 
INSTRUCTIONS 

*  ENDIT 
CLEAR 

g  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "DO  YOU  WISH  TO  CHANGE  SOCIAL  ROSTER 
INFORMATION"  GET  YESNO  PICTURE  "!" 
READ 

IF  YESNO  -  "Y" 
•USE  PRIVATE  INDEX  IDCODE 
•LOCATE  FOR  IDCODE=M_IDCODE 
•IF  FOUND ()  DO  FOLLOWING 

*  SET  FORMAT  TO  PRIVATE 

*  APPEND  BLANK 

*  REPLACE  IDCODE  WITH  M_IDCODE 

*  CLOSE  FORMAT 
•ENDIF 

•IF  .NOT.  TOUNDO   S4IDCODE  NOT  IN  PRIVATE  FILE 

*  WAIT  "ADDING  A  NEW  RECORD,   IDCODE  NOT 
TOUND . . PRESS  ; 

•RETURN  TO  CONTINUE..." 

*  SET  FORMAT  TO  PRIVATE 

*  APPEND  BLANK 

*  REPLACE  IDCODE  WITH  M_IDCODE 

*  CLOSE  FORMAT 
•ENDIF 

•ENDIF 

SET  CONFIRM  ON 

CASE  selectnurc  =  3 

*   DO  REMOVE  INFORMATION 

8  6,0  TO  10,79  DOUBLE 

8  7,10  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU 
WISH  TO       REMOVE:"   GET  M_CODE  PICTURE  "19999" 
8  8,10  SAY  "or  Press  Return  to  QUIT" 
READ 

•SEEK  M_CODE 
•IF  BLANK,  EXIT 

•IF  FOUND () 

•MESSAGE  =  "  IS  THIS  THE  PERSON  YOU  WANT  TO  DELETE? 


(Y/N)' 


*  SET  FORMAT  TO  CONFIRM 

*  READ  ANSWEP 

*  IF  ANSWER  IS  NO  "N" 

*  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

*  ENDIF 

*  IF  ANSWEP  IS  YES  "Y" 

*  ASK  "ARE  YOU  SURE  (Y/N) " 

*  IF  SURE  IS  YES  "Y" 

*  LOCATE  AND  DELETE  (IN  PERSON) 

*  USE  ABSENSE 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND ()  CONTINUE 

*  USE  CMEREQ 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND ()  CONTINUE 

*  USE  PRIVATE 

'  LOCATE  AND  DELETE 

*  IF  NOT  FOUND!)  CONTINUE 

*  ELSE  (ANSWEP  I S  NO  "N") 

*  CLEAR 
»  85,  0 

»  WAIT 

*  ENDIF 

'ELSE  (i.e.  NOT  FOUND) 

'  NOTIFY  USER  ID  NOT  FOUND,  GIVE  OPTION  TO  SEARCH 

LAST  NAME 

>  IF  CHOICE  IS  TO  SEEK  BY  LAST  NAME 

*  SEEK  LAST  NAME 

*  DISPLAY  ALL  WITH  THIS  LAST  NAME 

*  GIVE  USER  OPTION  TO  CHOSE  WHICH  RECORD 

*  USER  PICKS  RECORD  NUMBER 

*  GOTO  RECORD  SELECTED 

*  DISPLAY  LAST  NAME,  FIRST  NAME,  MI  and  FANK 

*  ASK  "IS  THIS  THE  PERSON  YOU  WISH  TO  DELETE? 


(Y/N)  ' 


•  READ  ANSWER 

•  IF  ANSWER  IS  NO  "N" 

•  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

•  ENDIF 

•  IF  AJ4SWEF  IS  YES  "Y" 

•  STORE  IDCODE  TO  M_IDCODE  t IDCODE  OF  CURR 
PERSON 

•  ASK  "ARE  YOU  SURE   (Y/N) " 

•  IF  SURE  IS  YES  "Y" 

•  LOCATE  M_IDCODE  AND  DELETE  (IN 
PERSON) 

•  USE  ABSENSE 

•  LOCATE  AND  DELETE 

•  IF  NOT  FOUND  0  CONTINUE 

•  USE  CMEREO 

•  LOCATE  M  IDCODE  AND  DELETE 

•  IF  NOT  FOUND  ()  CONTINUE 

•  USE  PRIVATE 

•  LOCATE  M_IDCODE  AND  DELETE 

•  IF  NOT  FOUND ()  CONTINUE 

•  ELSE  (ANSWER  IS  NO  "N") 

•  CLEAR 

*  es,o 

•  WAIT 

•  ENDIF 

•  ENDIF 

•  IF  CHOICE  IS  NOT  TO  SEARCH  FOR  LAST  NAME 

•  LOOP  TO  BEGINNING 

•  INDIF 
•ENDIF 

e  6, 0  TO  8,79  DOUBLE 

8  7,15  SAY  "DO  YOU  WISH  TO  CHANGE  SOCIAL  ROSTER 
INFORMATION"  GET  YESNO  PICTURE  "I" 
READ 
•IF  YESNO  -  "Y" 

•USE  PRIVATE  INDEX  IDCODE 
•LOCATE  FOR  IDCODE«M_IDCODE 
•IF  FOUND!)  DO  FOLLOWING 

•SET  FORMAT  TO  DELPRIVATE 
•ASK  "ARE  YOU  SURE  (Y/N) " 
•IT  SURE  IS  YES  "Y" 

•  DELETE 

•ELSE  (ANSWEP  IS  NO  "N") 

•  CLEAR 

*  85,0 

*  WAIT 
•ENDIF 

•ENDIF 

•IF  .NOT.  FOUND ()   ttlDCODE  NOT  IN  PRIVATE  FILE 
•    WAIT  "IDCODE  NOT  FOUND.. PRESS  RETUF.N  TO 
CONTINUE.  .  ." 

•ENDIF 

SET  TALK  ON 

CLEAR 

8  2,0  SAY  '  ' 

?  ' PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 

DELETION' 
•PACK  ALL  DATABASES  USED 
(PERSON, CMEREQ, ABSENCE, PRIVATE)  SET  TALK  OFF 

set  confirm  orr 

STOP.E  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  4 

•   DO  REVIEW  INFORMATION  ttONLY  PERSON  FILE 
BROWSE  NOAPPEND  NOMENU 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait^subst 

READ 

SET   CONFIRM   ON 
END  CASE 

ENDDO    T 

RETURN 

'     F^F:     rMF.NUl.PPG 


Program. 


PMBNU2.PRC 


•  Author...:     ELBERT    T.     SHAW    t    JOAN    ZIMMERMAN 

•  Date :     02/02/89 

•  Notice. :Copyright (c)     1989.ELBEPT    T.     SHAW    (.    JOAN    ZIMMERMAN, 
All    Rights    Reserved 

•  Notes. ... :UTDATE    TDA    LIST 
SET    TALK    OFF 

SET    BELL    OFF 
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SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  TDA 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  beading 
CLEAR 

8  2,  0  TO  14,79  DOUBLE 

6  3,23  SAY  [UPDATE    TDA    LISTING] 

8  4, 1  TO  4,78  DOUBLE 

* display  detail  lines 

8   7,30  SAY  [1.  ADD  A  TEA  POSITION] 

8   8,30  SAY  [2.  CHANGE  A  TDA  POSITION'S  INFORMATION] 

8   9,30  SAY  [3-  REMOVE  A  TDA  POSITION] 

8  10,30  SAY  [4.  REVIEW  ALL  TDA  POSITIONS] 

e  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  seleetnura 

e  14,33  SAY  "  select 

8  14,42  GET  seleetnura  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  seleetnura  ■  0 

CLEAR  ALL 

RXTURN 

CASE  selectnum  =  1 

*  DO  ADD  INFORMATION 

*  ALLOWS  YOU  TO  ADD  A  NEW  TDA  POSITION  TO  THE  MASTER 
LIST 

TRYING  »  .T. 

DO  WHILE  TRYING 

SET  FORMAT  TO  TDAINPUT 
READ 

CLOSE  FORMAT 
USE  TDA 
GO  TOP 

LOCATE    FOR    TDA_PARA=M_TDAPARA    .AND. 
TDA_LINE=M_TDALINE     .AND.     TDA_POSN=M_TDAPOSN 
IF    FOUND  () 
CLEAR 
SET    FORMAT    TO    OCCUPIED 
READ 

CLOSE  FORMAT 
ELSE 

8  12,0  TO  14,79  DOUBLE 

8  13,5  SAY  "TDA  POSITION  NOT  IN  CURRENT  FILE, 
PRESS  ; 

RETURN  TO  ADD  IT.  .  .  " 
WAIT  "  " 
CLEAR 

M_AUTH  =  SPACE (1) 
8  6,0  TO  8,79 
8  7,15  SAY  "IS  THIS  AN  AUTHORIZED  POSITION? 

(Y/N)"; 

GET  M_AUTH  PICTURE  " I " 
READ 

SET  FORMAT  TO  TDA 
APPEND  BLANK 
IF  M_AUTH  -  "Y" 

REPLACE  AUTH  WITH  1 
ELSE 

REPLACE  AUTN  WITH  0 
ENDIF 

REPLACE  TDA_PARA  WITH  MJTDAPARA,  ; 
TDA_LINE  WITH  M_TDALINE,  ; 
TDA_POSN  WITH  M_TDAPOSN 
READ 

CLOSE  FORMAT 
ENDIF 
ENDDO 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
vait_subst 

READ 

SET  CONFIRM  ON 

CASE  seleetnura  =  2 

*  DO  CHANGE  INFORMATION 

*  ALLOWS  YOU  THE  CAPABILITY  TO  CHANGE  A  TDA 
POSITION'  S        INFO 

TRYING  =  .T. 
DO  WHILE  TRYING 

SET  FORMAT  TO  TDAINPUT 

READ 

USE  TDA 

GO  TOP 

LOCATE    FOP    TDA_PAPA«M_TDAFARA    .AND. 
TDA_LINE«M_TDALINE     .AND.     TDA_POSN»M_TDAPOSN 

IF    FOUND  () 
CLEAR 
IF    AUTH    -    0 

8  6,0  TO  8,79 


8  7,15  SAY  "DO  YOU  WANT  TO  CHANGE  THIS  TO 
AN   AUTHORIZED  POSITION?  (Y/N)"  GET  M_AUTH  PICTURE  "I" 
PEAD 
IF  M  AUTH  =  "Y" 

PEPLACC  AUTH  WITH  1 
ENDIF 

SET  FORMAT  TO  TDA 

READ  (  CANNOT  CHANGE  THE  TDA  POSITION 
CLOSE  FORMAT 
ELSE  CI  IF  AUTH  -  0 

e  6,0  TO  8,79 

e  7,15  SAY  "DO  YOU  WANT  TO  CHANGE  THIS  TO 
AN   UNAUTHORIZED  POSITION?  (Y/N)"  GET  M_AUTH  PICTURE  "!" 
RXAD 
IF  M_AUTB  -  "Y" 

REPLACE  AUTH  WITH  0 
ENDIF 

SET  FORMAT  TO  TDA 

READ  t  CANNOT  CHANGE  THE  TDA  POSITION 
CLOSE  TORMAT 
ELSE 

e  12,0  TO  14,79  DOUBLE 

8  13,5  SAY  "TDA  POSITION  NOT  IN  CURRENT  TILE, 
PRESS  ; 

RETURN  TO  TRY  AGAIN..." 
WAIT  "  " 
LOOP 
ENDIF 
ENDDO 

SET  CONFIRM  OFr 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
walt_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 
«   DO  REMOVE  INFORMATION 

«   ALLOWS  YOU  TO  DELETE  A  NO  LONGER  AUTHORIZED  TDA 
POSITION 
TRYING  -  .T. 
DO  WHILE  TRYING 

SET  FORMAT  TO  TDAINPUT 
READ 
USE  TDA 
GO  TOP 

LOCATE  FOR  TDA_PARA=M_TDAPARA  .AND. 
TDA_LINE=M_TDALINZ  .AND.  TDA_POSN-M_TDAPOSN 
IF  FOUND!) 

YESNO  -  SPACE (1) 
CLEAR 
8  2,0 

?  "JOBTITLE  APC  CODE" 

1    JOBTITLE, APC 
8  6,0  TO  8,7  9  DOUBLE 

8  7,15  SAY  "IS  THIS  THE  TDA  POSITION  YOU  WANT 
TO   DELETE?  (Y/N)"  GET  YESNO  PICTURE  "I" 
READ 

IF  YESNO  -  "Y" 
DELETE 
USE  PERSON 

INDEX    ON   TDA_PARA     .AND.     TDA_LINE     .AND. 
TDA_POSN    TO  TEMP 

SET    INDEX    TO   TEMP 

LOCATE    FOR    TDA_PARA-M_TDAFARA    .AND. 
TDA_LINE-M_TDALINE     .AND.     TDA_POSN«M_TDAPOSN 
IF    FOUND)) 

REPLACE    TDA_PARA    WITH    0,     ; 
TDA_LINE    WITH    0,     ; 
TDA_POSN    WITH    0 
CLEAR 

8    6,0    TO    9,7  9   DOUBLE 

8  7,5  SAY  "FOUND  "+RANK+"  "+LNAME+"  WHO 
IS 

OCCUPYING  THE  DELETED  POSITION,  IDCODE 
IS"+STP (IDCODE,  5) 

8  8,5  SAY  "BE  SURE  YOU  UPDATE  THIS 
PERSON'S  TDA      POSITION  WITH  A  VALID  TDA  POSITION!" 
8  12,0 
WAIT 
ENDIF 
ELSE  Ik    YESNO-  "N" 

LOOP 
ENDIT 


ELSE  tt  POSITION  WAS  NOT  FOUND 
8  12,0  TO  14,79  DOUBLE 

8  13,5  SAY  "TDA  POSITION  NOT  IN  CURRENT  FILE, 
PRESS  ; 

RETURN  TO  TRY  AGAIN. . ." 
WAIT  "  " 
LOOP 
ENDIF 


ENDDO 
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SET  INDEX  TO 
ERASE  TEMP.NDX 
SET  TALK  ON 
CLEAP 

8  2,0  SAY  '  ' 

?  ' PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  TOR 
DELETION' 
PACK 

SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  4 

»   DO  REVIEW  INFORMATION 

*   ALLOWS  YOU  TO  REVIEW  THE 
COMPLETE  FILE 

INDEX  ON  TDA_PARA  .AND.  TDA_LINE  .AND.  TDA_POSN  TO 
TEMP 

SET  INDEX  TO  TEMP 

BROWSE  NOAPPEND  NOMENU 

ERASE  TEMP.NDX 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

§  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 
END CASE 


ENDDO  T 

RETURN 

*  EOF:  PMENU2.PRG 


Program. . 


PMEHU3  .  PRG 


*  Author...:  ELBERT  T.  SHAW  &    JOAN  ZIMMERMAN 

*  Date :  02/02/89 

*  Notice:  Copyright (c)  1989, ELBERT  T.  SHAW  (  JOAN  ZIMMERMAN, 
All  Rights  Reserved 

*  NOTES  :  QUICK  UPDATE  FROM  RIR  REPORT 
SET  TALK  OFF 

SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
DSE  PERSON 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12, 79  DOUBLE 

8    3,13    SAY     [QOICK         UPDATE  FPOM         RIR         R 

E    P    O    R   T] 

8    4,1    TO    4,78   DOUBLE 

* display  detail  lines 

8   7,23  SAY  [1.  Update  Losses) 

8   8,23  SAY  [2.  Update  Changes  to  TDA  Positions] 

8  10,  23  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  ■=  0 
CLEAR  ALL 
RETURN 

CASE  selectnum  =  1 
*   DO  Update  Losses 


•DO  WHILE  TRYING  It    MASTER  LOOP  FOR  MULTIPLE 


ENTRIES 


M_UPDATETYPE  *  1 

8  6,0  TO  9,7  9  DOUBLE 

8  7,10  SAY  "HAS  THIS  PERSON  ACTUALLY  DEPARTED  OR  IS 
THIS     AN  UPDATE  TO  A  PROJECTED  LOSS  DATE?  (ACTUAL-0, 
UPDATE   DATE-1)"  GET  M_UPDATETYPE  PICTURE  "9"  RANGE  0,1 

READ 

8  15,0  TO  19,79  DOUBLE 

8  16,10  SAY  "ENTER  THE  ID  CODE  OF  THE  PEPSON 
WHO"+IFF (M_UPDATETYPE  =1,  "LOSS  DATE  NEEDS  CHANGING", 


"DEPARTED") +": "  GET  M_CODE  PICTURE  "19999" 
8  17,10  SAY  "or  Press  Return  to  QUIT" 
READ 

•USE  TEPSON 
•SEEK  H_COCE 
•IT  BLANK,  EXIT 
•IT  FOUND!) 

*  DISFLAY  LAST  NAME,  riPST,  AND  RANK 

*  MESSAGE  -  "IS  THIS  THE  PERSON  YOU  WISH  TO 
MODIFY?  (Y/N)" 

*  SET  FORMAT  TO  CONFIRM 

*  IF  ANSWER  IS  NO  "N" 

*  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

*  ENDIF 

*  IF  ANSWER  IS  YES  "Y" 

*  IF  MJJPDATETYPE  IS  1   tlAPPEND  NEW  LOSS  DATE 

*  CLEAR 

*  e  6,0  TO  8,79  DOUBLE 

*  e  7,15  SAY  "ENTER  NEW  LOSS  DATE: 
(MM/DD/YY)"; 

*  GET  M_LOSS  PICTURE  "99/99/99" 

*  READ 

*  REPLACE  ALOSS  WITH  M_LOSS 

*  LOOP  TO  DO  ANOTHEP  PERSON 

*  ENDIF 

*  ASK  "ARE  YOU  SURE  (Y/N) " 

*  IF  SURE  IS  YES  "Y" 

*  LOCATE  AND  DELETE  (IN  PEPSON) 

*  USE  ABSENSE 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND!)  CONTINUE 

*  USE  CMEREQ 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND  ()  CONTINUE 

*  USE  PRIVATE 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND))  CONTINUE 

*  ELSE  (ANSWER  IS  NO  "N") 

*  CLEAR 

*  85,0 

*  WAIT 

*  ENDIF 
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•ELSE  (i.e.  NOT  FOUND) 

*  NOTIFY  USER  ID  NOT  FOUND,  GIVE  OPTION  TO  SEARCH 
LAST  NAME 

*  IF  CHOICE  IS  TO  SEEK  BY  LAST  NAME 

*  SEEK  LAST  NAME 

*  DISPLAY  ALL  WITH  THIS  LAST  NAME 

*  GIVE  USER  OPTION  TO  CHOSE  WHICH  ID  CODE 

*  USER  PICKS  ID  CODE 

*  GOTO  ID  CODE  SELECTED 

*  DISPLAY  LAST  NAME,  FIRST  NAME,  MI  and  RANK 

*  MESSAGE-"IS  THIS  THE  PERSON  YOU  WISH  TO 
DELETE?  (Y/N) 

*  SET  FORMAT  TO  CONFIRM 

*  READ  ANSWER 

*  IF  ANSWER  IS  NO  "N" 

*  LOOP  TO  TRY  ANOTHER  PERSON  CODE 

*  ENDIF 

*  IF  ANSWER  IS  YES  "Y" 

*  STORE  IDCODE  TO  M_IDCODE 

*  ASK  "ARE  YOU  SURE  (Y/N) " 

*  IF  SURE  IS  YES  "Y" 

*  LOCATE  M_IDCODE  AND  DELETE  (IN 
PERSON) 

*  USE  ABSENSE 

*  LOCATE  AND  DELETE 

*  IF  NOT  FOUND!)  CONTINUE 

*  USE  CMEREQ 

*  LOCATE  M_IDCODE  AND  DELETE 
«  IF  NOT  FOUND!)  CONTINUE 

*  USE  PRIVATE 

*  LOCATE  M_IDCODE  AND  DELETE 

*  IF  NOT  FOUND ()  CONTINUE 

*  ELSE  (ANSWER  IS  NO  "N") 

*  CLEAR 

*  85,0 

*  WAIT 

*  ENDIF 

*  ENDIF 

*  IF  CHOICE  IS  NOT  TO  SEARCH  FOP  LAST  NAME 

*  LOOP  TO  BEGINNING 

*  ENDIF 
•ENDIF 
•ENDDO 


SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIPM  ON 
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CASE  selectnum  «=  2 

*   DO  Upda^p  Changes  to  TDA  Positions 

•DO  WHILE  TRUE 

•ALLOWS  YOU  TO  CHANGE  THE  TDA  POSITION  FROM  THE  PIP 

SET  roRMAT  TO  PEP.PIR    ti  screen  of  memory  variable 

READ 

•IF   M_TDAPARA    -    0 

•  EXIT 
•ENDIF 
•USE  PERSON 

•LOCATE  FOR  TDA_PARA-M_TDAPARA  .AND. 
TDA_LINE-M_TDALINE  «.AND.  TDA_POSN=M_TDAPOSN 

•IF  FOUND!)..  MEANS  THAT  THE  NEW  POSITION  IS 
OCCUPIED,  GIVE         CHOICES  AS  LISTED  BELOM 

•  STORE  IDCODE  TO  OLDPERSON   HRECORD  WHO  THE 
PERSON      *     CLEAR 

•  e  7,0 

•  SET  FORMAT  TO  CHOICE 

•  READ 

•  DO  CASE 

•  CASE  ANSMER-1 

•  USE  TDA 

•  C<  LOOK  FOR  THE  TDA  TO  MAKE  SUPE  IT  IS 


O.K. 


PRESS    RETURN 


NOT  AN 
AGAIN. . , 


•  LOCATE  FOR  TDA_PARA=M_TDAPARA  .ANT. 
TDA_LINE«M_TDALINE  .AND.  TDA_POSN=M_TDAPOSN 

•  IT  FOUND  O   C i AUTHORIZED  SLOT 

•  USE  PERSON 

•  LOCATE  FOR  IDCODE-=M_IDCODE   ((  PEPSON 
CHANGE  POSN 

•  IF  .NOT.  FOUND!) 

•  CLEAR 

•  96, 0  TO  8, 79  DOUBLE 

•  §  7,15  SAY  "IDCODE  DOES  NOT  EXIST, 
TO  TRY  AGAIN. . " 

LOOP 
ENDIF 

REPLACE  TDA_PARA  WITH  MTDAPARA,  : 
TDA_LINE  WITH  M_TDALINE,  ; 
TDA_POSN  WITH  M_TDAPOSN 
GO  TOP 

LOCATE  FOR  IDCODE-OLDPERSON 
REPLACE  TDA_POSN  WITH  99   44FUT  THE 
PERSON  IN  EXCESS 
ELSE 

8  6,0  TO  8, 79  DOUBLE 

(  1,5  SAY  "TDA  POSITION  ENTERED  IS 
AUTHOPIZED  TDA  POSITION" 
CHECK  INFORMATION  AND  PRESS  RETURN  TO  TRY 


PRESS  RETURN 


•  WAIT  "  " 

•  LOOP 

•  ENDIF 

•  REPLACE  TDA_POSN  WITH  99 

•  TRY  -  .F. 

•  LOOP 

•  CASE  ANSWER=2 

•  USE  TDA 

•  U    LOOK  FOF  THE  TDA  TO  MAKE  SURE  IT  IS 

•  LOCATE  FOR  TDA_FARA-M_TDAFARA  .AND. 
TDA_LINE-M_TDALINE  .AND.  TDA_POSN-M_TDAPOSN 

•  IF  FOUND!)    SSAUTHORIZED  SLOT 

•  USE  PEPSON 

•  LOCATE  FOP  IDCODE=M_IDCODE   U  PERSON 
CHANGE  POSN 

•  IF  .NOT.  FOUND!) 

•  CLEAP 

•  8  6,0  TO  8,79  DOUBLE 

•  !  7,15  SAY  "IDCODE  DOES  NOT  EXIST, 
TO  TRY  AGAIN. . " 

LOOP 
ENDIF 

REPLACE  TDA_PARA  WITH  M_TDAPARA,  ; 
TDA_LINE  WITH  M_TDALINE,  ; 
TDA_POSN  WITH  9  9 
GO  TOP 

LOCATE  FOR  IDCODE=OLDPEPSON 
REPLACE  TDA_FOSN  WITH  99   44PUT  THE 
PERSON  IN  EXCESS 
ELSE 

8  6,  0  TO  8,79  DOUBLE 

8  7,5  SAY  "TDA  POSITION  ENTERED  IS 
*  AUTHORIZED  TDA  POSITION 

CHECK  INFORMATION  AND  PRESS  RETURN  TO  TRY 

WAIT  "  " 

LOOP 
ENDIF 
TRY  ■=  .F. 
LOOP 

CASE  ANSWER=2 


•  LOOP 

•  ENDCASE 

•ELSE  HFEPSON    NOT    FOUND!)     IN    POSITION    DESIRED 

•  CLEAf 

•  USE    TDA 

•  LOCATE    FOP    TDA_PARA=M_TDAPAPA    .AND. 
TDA_LINE-M_TDALINE     .AND.     TDA_FOSN«M_TDAPOSN 

•  IT    FOUND!)       * » AUTHORIZED    SLOT 

•  USE    PERSON 

•  LOCATE  FOR  IDCODE-M_IDCODE   IS  PERSON  TO 
CHANGE  POSN 

•  IF  .NOT.  FOUND!) 

•  CLEAR 

•  |  6,0  TO  8, 79  DOUBLE 

•  8  7,15  SAY  "IDCODE  DOES  NOT  EXIST,  PRES 
RETURN  TO         TRY  AGAIN.." 

•  LOOP 

•  ENDIF 

•  REFLACE  TDA_PARA  WITH  M_TDAPARA,  ; 

•  TDA_LINE  WITH  M_TDALINE,  ; 

•  TDA_POSN  WITH  M_TDAPOSN 

•  ELSE 

•  8  6,0  TO  8,79  DOUBLE 

•  8  7,5  SAY  "TDA  POSITION  ENTERED  IS  NOT  AN 
AUTHORIZED  TDA  POSITION" 

•CHECK  INFORMATION  AND  PRESS  RETURN  TO  TRY 
AGAIN. . . " 

•  WAIT  "  " 

•  LOOP 

•  ENDIF 

SET  CONFIRM  OFF 

STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

•  EOF:  PMENU3.PRG 

AZ 


Program. 


PMKNU4.PRC 


•  Author...:  ELBERT  T.  SHAW  s  JOAN  ZIMMERMAN 

•  Date :  02/02/89 

•  Notice:  Copyright  (c)  1989, ELBERT  T.  SHAW  i    JOAN 
ZIMMERMAN,  All  Rights  Reserved 

•  Notes....:  UPDATE  CME  LIST/BUDGET 

SET  TALK  OrF 

SET  BELL  OFF 

SET  ESCAPE  OFF 

SET  CONFIRM  ON 

DO  WHILE  .T. 

•  Display  menu  options,  centered  on  the  screen. 

•  draw  menu  border  and  print  heading 
CLEAR 

§  2,  0  TO  14, 79  DOUBLE 

!  3,19    SAY     [UPDATE         CME  INFORMATION] 

8  4, 1    TO    4, 78   DOUBLE 

•  display  detail  lines 

8   7,20  SAY  [1.  Update  Allocation  for  Fiscal  Year] 

8   8,20  SAY  [2.  Update  CME  Requests] 

8   9,20  SAY  [3.  Update  CME  Requests  with  Actual  Costs] 

8  10,20  SAY  [4.  Print  Reports] 

8  12,  20  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  14, 33  SAY  "  select 

8    14,42  GET    selectnum    PICTURE    "9"    RANGE    0,4 

READ 

DO    CASE 

CASE  selectnum  ■  0 
CLEAP.  ALL 
RETURN 

CASE  selectman  =  1 

*   DO  Update  Allocation  for  riscal  Year 

DO  proenu4_l 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 
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CASE  selectnum  «  2 

*  DO  Update  CUE  Requests 

DO  PMENU4_2 

SET  CONTIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  OET 
wait  subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 

*  DO  Update  CME  Requests  with  Actual  Costs 

DO  PMENU4_3 

SET  CONTIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  OET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  4 

*  DO  Print  Reports 

DO  PMENU4_4 

SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_aubst 

READ 

SET  CONFIRM  ON 
END  CASE 

ENDDO  T 

RETURN 

*  EOF:  PMENU4.PRG 


Program. 


PMENU4  l.PRG 


«  Author...:  ELBERT  T.  SHAM  (  JOAN  ZIMMERMAN 

*  Date :  02/02/89 

*  Notice...:  Copyright  (c)  1989, ELBERT  T.  SHAM  t    JOAN 
ZIMMERMAN,  All  Rights  Reserved 

*  Notes....:  UPDATE  ALLOCATION  FOP  FY 


SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
MTY  -  0 

*  Clear  Screen  for  FY  input  an  allow  for  the  user  to  select 
the  riscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 

CLEAR 

§6, 0  to  8, 79  DOUBLE 

§7,15  SAY  "Enter  the  Fiscal  Year  for  the  CME  Allocations:"  ; 

GET  M_FY  PICTURE  "99" 
READ 

DO  MBILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 

CLEAR 

M_ALLOCATION  -  0 
6  6,0  TO  9,7  9  DOUBLE 

8  7,15  SAY  "ENTEF  ALLOCATION  FOP  FISCAL  YEAR 
"+STR (M_FY, 2) 

GET   M_ALLOCATION   PICTURE  "999999.99" 
S  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 
READ 
IT  M_ALLOCATI0N  -  0 

EXIT 
ENDIF 

USE  CMEALLOC 
LOCATE  FOR  FY"M_FY 
IT  TOUNDO 

CLEAR 

8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "ALLOCATION  FOR  FISCAL  YEAP  "+STR (M_FY, 2) +  " 
ALREADY  EXISTS"; 

8  8,15  SAY  "PRESS  RETURN  TO  EDIT  IT" 


MAIT  "  " 

SET  FORMAT  TO  CMEALLOC 

READ 

LOOP 
ELSE   u  ALLOCATION  TOR  TY  IS  A  NEW  ONE 

APPEND  BLANK 

REPLACE  ALLOCATION  MITH  M_ALLOCATION 

REPLACE  FY  MITH  M_rY 

LOOP 
ENDIF 
ENDDO  T 
RETURN 

*  EOF :  PMENU4_1 . PRG 
*Z 


Program. 


PMUTU4  2. PRG 


*  Author...:  ELBERT  T.  SHAM  t    JOAN  ZIMMERMAN 

*  Date :  02/02/89 

*  Notice...:  Copyright  (c)  1989, ELBERT  T.  SHAM  (  JOAN 
ZIMMERMAN,  All  Rights  Reserved 

*  Notes....:  UPDATE  CME  REQUESTS 


SET  TALK  OFF 
SET  BELL  OrF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_FY  -  0 

*  Clear  Screen  for  FY  input  an  allow  for  the  user  to  select 
the  riscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  TY 

CLEAR 

86,0  to  8,  79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  for  the  CME  Allocations:"  ; 

GET  M_FY  PICTURE  "99" 
READ 

DO  MHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8  3,  21    SAY     [UFDATE         CME         REQUESTS] 

8  4, 1    TO    4, 78   DOUBLE 

*  display    detail    lines 

8       7,30    SAY     [1.    ADD    A    NEM    CME    REQUEST    FOR    FY 
)+STR<M_FY,  2) 

8       8,30    SAY     [2.     CHANGE    A    CME    REQUEST'S    INFORMATION    FOP    FY 
)+STR(M_rY,2) 

8       9,30    SAY     [3.    DELETE    A    CME    REQUEST    TOR    FY    ] +STR (M_FY, 2) 

8    10,30    SAY     (4.     REVIEM   ALL    CME    REQUESTS    FOR    FY 
]+STR(M_rY,2) 

e    12,     30    SAY    '0.     EXIT' 

STORE  0  TO  selectnum 

e  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  selectnum  =  0 
CLEAR  ALL 
RETURN 

CASE  selectnum  »  1 

*   DO  ADD  INFORMATION 

DO  WHILE  . T. 
e  6,0  TO  9,79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO  ADD 
THE       REQUEST:  "; 

GET  M_IDCODE  PICTURE  "1999" 
e  8,15  SAY  "OR  FPESS  RETURN  TO  QUIT" 

IF  M_IDCODE«  "" 

EXIT 
ENDIF 

USE  PERSON 

LOCATE  FOR  IDCODE-M_IDCODE 

IF  FOUND O  ((PERSON  DOES  EXIST  IN  MASTER  FILE 

ANSMEP  ■=  "  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N) 

SET  FORMAT  TO  CONFIRM 
READ 
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IF  ANSWER  »  "Y"  S4the  right  person 
USE  CMEREQ 

SET  riLTER  TO  FY=M_FY 
rjr,    T,  ,r 

SET  rORMAT  TO  CMEREQ 
APPEND  BLANK 

REPLACE  IDCODE  WITH  M_IDCODE 
REPLACE  FY  WITH  M_FY 
READ 

REPLACE  TOTALCOST  WITH 
TRAVELCOST+PERDIEM+REGFEE+REIMB 
CLOSE  FORMAT 
SET  FILTER  TO 
LOOP 
ELSE 

LOOP 
ENDIF 
ELSE 

8  6,0  TO  8,7  9  DOUBLE 

8  7,15  SAY  "THERE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
LOOP 
ENDIF 
ENDDO 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
vait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  -  2 

*   DO  CHANGE  INFORMATION 

DO  WHILE  .T. 

8  6,0  TO  9,79  DOUBLE 

8  7,15  SAY  "ENTEP  THE  ID  CODE  OF  THE  PERSON  YOU 
WANT  TO       CHANGE:  "  GET  M_IDCODE  PICTURE  "1999" 
§  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M_IDCODE=  "" 

EXIT 
ENDIF 

USE  PERSON 

LOCATE  FOR  IDCODE=M_IDCODE 

IF  FOUND()  ttPERSON  DOES  EXIST  IN  MASTER  FILE 

ANSWER  -  "  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N) 

SET  FORMAT  TO  CONFIRM 

READ 

IF  ANSWER  =  "Y"  ttthe  right  person 

USE  CMEREQ 

SET  FILTER  TO  IDCODE-M_IDCODE  .AND.  TY-M_FY 

CLEAR 

e  6,o 

DISPLAY  FIELDS  IDCODE, TYPE, START, END  WHILE 
IDCODE-M_IDCODE 
8  20,  0  CLEAR 

8  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  THE 
CME  REQUEST  YOU  DESIRE  TO  CHANGE.   (l-"+ 

STR  (RECCOUNT  ()  ,  4)  +") 

GET  RECORD  PICTURE  "9999" 
READ 

IF  RECORD  >  0  .AND.  RECORD  <  RECCOUNT  () 
CLEAR 

DO  WHILE  .T. 
8  6,0  TO  8, 79  DOUBLE 

8  7,5  SAY  "WILL  COSTS  BE  ACTUAL  COSTS  OR 
ESTIMATED; 

(ENTER  AN  -A-  FOR  ACTUAL  OR  AN  -E-  FOR 
ESTIMATED)"  GET  M_CCODE   PICTURE  "!" 

IT  M_CCODE  ♦  "A"  .OR.  M_CCODE  I     "E" 
CLEAR 

8  6, 0  TO  8,79  DOUBLE 

8  7,15  SAY  "YOU  HAVE  ENTERED  A  WRONG 
LETTER,  PPESS  FETUFN  TO  TPY  AGAIN.." 

WAIT  "  " 
LOOP 
ENDIF 

GOTO  RECORD 
SET  FORMAT  TO  CMEREQ 
REPLACE  C_CODE  WITH  M_CCODE 
READ 

REPLACE  TOTALCOST  WITH 
TRAVELCOST+PERDIEM+REGFEE+REIMB 
CLOSE  FORMAT 
EXIT 
ENDDO 
ELSE 

8  20,0  CLEAR 

8  23,5  SAY  "NO  SUCH  RECORD: 
"  +  STR (RECORD,  4) 


?  CHR(7) 
WAIT 
ENDIF 

SET  FILTER  TO 
LOOP 
ELSE 

SET  FILTER  TO 
LOOP 
ENDIF 
ELSE 

8  6,  0  TO  8,79  DOUBLE 

8  7,15  SAY  "THERE  IS  NOT  A  PERSON  WITH  TRAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
LOOP 
ENDIF 
ENDDO 
SET  FILTER  TO 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  -  3 

*   DO  REMOVE  INFORMATION 

DO  WHILE  .T. 
8  6, 0  TO  9, 79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO 
DELETE        THEIR  REQUEST:  "   GET  M_IDCODE  PICTURE  " ! 999" 
e  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M_IDCODE-  "" 

EXIT 
ENDIF 

USE  PERSON 

LOCATE  FOR  IDCODE=M_IDCODE 

IF  TOUNDO  UPEPSON  DOES  EXIST  IN  MASTER  FILE 
RIGHT  -  "  " 
SET  FORMAT  TO  CMEVAL 
READ 

IF  RIGHT  «  "Y"  lithe  right  person 
USE  CMEREQ 

SET  FILTER  TO  IDCODE-M_IDCODE  .AND.  rY-M_FY 
CLEAR 
8  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, START, END  WHILE 
IDCODE=M_IDCODE 
e  20,  0  CLEAR 

8  22,0  SAY  "ENTEF  THE  RECORD  NUMBEP  OF  THE 
CME  REQUEST  YOU  DESIRE  TO  DELETE.   (1- 

"+ STR (RECCOUNT () , 4)+") "; 

GET  RECORD  PICTURE  "9999" 
READ 

IF  RECORD  >  0  .AND.  RECORD  <  RECCOUNT!) 
GOTO  RECORD 

SET  TORMAT  TO  DELCMEREQ 
READ 
IT  UPFER (MAYBE)-  "Y" 

DELETE 
ENDIF 

CLOSE  FORMAT 
ELSE 

8  20,0  CLEAR 

8  2  3,5  SAY  "NO  SUCH  RECORD: 
"+STR(PECORD, 4) 

?  CHR(7) 
WAIT 
ENDIF 
LOOP 
ELSE 

8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "THERE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
L"-P 
ENDIF 
ENDDO 

SET  FILTER  TO 
SET  TALK  ON 
CLEAR 

8  2,0  SAY  '  ' 

?  ' PACKING  DATABASE  TO  REMOVE  RECOPDS  MAPKED  FOR 
DELETION' 

PACK 

SET  TALK  OFF 

SET  CONFIRM  OFF 
STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
walt_subst 

READ 
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SET  CONFIRM  ON 

CASE  selectnum  =  4 
•   D"  rE  ITW  nif-rmTTON 
SELECT  A 
USE  CMEREQ 

INDEX  ON  IDCODE  TO  TEMF 
SELECT  B 
OSE  PERSON 

INDEX  ON  IDCODE  TO  TEMPI 

JOIN  WITH  A  TO  TEMPJOIN  FOR  IDCODE-A->IDCODE  FIELDS 
A->IDCODE,B->RANK,B->rNAME, ; 

B->LNAMX,A->TYPE,A->START,A->END,  ALLOCATION,  A- 
>PURFOSE, ; 

A->TVLCOST, A->PERDIEM, A->REGFEE, A->REIMB, A- 
>TOTALCOST,  ; 

A->C_CODE,A->FY 
USE  TEMPJOIN 
SET  FILTER  TO  FY-M_FY 
BROWSE  NOAPPEND  NOMEND 
ERASE  TEMP.NDX 
ERASE  TEMP1.NDX 
ERASE  TEMPJOIN. DBF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Piasi  any  key  to  continue...'  GET 
weit_aubst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 
RETURN 

•  EOF:  PMENU4  2.PRG 


Program . 


PMENU4  3.PRC 


*  Author...:  ELBEPT  T.  SHAW  s  JOAN  ZIMMERMAN 

*  Date :  02/02/89 

*  Notice...:  Copyright  (c)  1989, ELBERT  T.  SHAW  i    JOAN 
ZIMMERMAN,  All  Rights  Reserved 

»  Notes....:  UPDATE  CME  REQUEST  WITH  ACTUAL  COSTS 


SET  TALK  OFF 
SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
M_FY  -  0 

*  Clear  Screen  for  FY  input  an  allow  for  the  user  to  select 
the  Fiscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 

CLEAP 

§6,0  to  8,  79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  for  the  CME  Allocations:"  ; 

GET  M_FY  PICTURE  "99" 
READ 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAP 

M_IDC0DE  -  SPACE (5) 
RECORD  ■  0 

8  6,0  TO  8, 79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU  WANT  TO 
UPDATE  WITH  ACTUAL  COST  OF  TRAVEL"; 
GET  M_IDC0DE   PICTURE  "!999" 
READ 

USE  CMEREQ 

SET    FILTER    TO    IPCODE=M_ID0ODE     .AND.     FY=M_FY 
CLEAR 
8    6,0 

DISPLAY    FIELDS    IDCODE, TYPE, STAPT, END    WHILE 
IDCODE-M_IDCODE 
e    20,     0    CLEAR 

e    22,0    SAY    "ENTER   THE    RECORD    NUMBER    OF    THE    CME    REQUEST 
YOU    DESIRE    TO    CHANGE.      ( 1 -"  +  STR (RECCOUNT ( )  ,  4 ) +" ) " ; 

GET    RECORD    PICTURE    "9999" 
READ 
IF    RECORD    >    0    .AND.     RECORD    <    RECCOUNT ( ) 

GOTO    RECORD 

SET  FORMAT  TO  UPCMEPEQ 

REPLACE  C_CODE  WITH  A 

READ 


REPLACE  TOTALCOST  WITH  TPAVELCOST+PERDIEM+REGFEE+REIMB 

CLOSE  TORMAT 
ELSE 

8  20,  0  CLEAR 

8  :.',b  BAY  "DO  SUCH  RECORD:  "  +  STP  (PECOFD,  4 ) 

?  CflR(7) 

WAIT 
ENDIF 
ENDDO    T 
RETURN 

*    EOF:     PMENU4_3.PRG 
*Z 


w 


*  Program.  . : 

PKEWU44.PRG 

*  Author...:    ELBERT    T.     SHAW    t    JOAN    ZIMMERMAN 
«   Date :    02/02/89 

*  Notice...:    Copyright    (c)    1989,    ELBERT  T.    SHAW   t    JOAN 
ZIMMERMAN,    All   Rights    Reserved 

*  Notes . . . . :       PRINT    CME    REPORTS 


SET  TALK  OFF 

set  bell  orr 

SET  ESCAPE  OFr 
SET  CONFIRM  ON 
M_FY  -  0 

*  Clear  Screen  for  TY  input  an  allow  for  the  user  to  select 
the  Fiscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 

CLEAR 

86,0  to  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  for  the  CME  Allocations:"  ; 

GET  M_FY  PICTURE  "99" 
READ 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  11,79  DOUBLE 

8  3,23  SAY  [PRINT    CME    REPORTS] 

8  4,1  TO  4, 78  DOUBLE 

*  display  detail  lines 

8   7,30  SAY  [1.  ESTIMATED  CME  EXPENSES  REPORT  FOR  FY) 

+STR(M_FY,2) 
8   8,30  SAY  [2.  ACTUAL  CME  EXPENSES  REPORT  FOR 
FY) +STR(M  FY, 2) 

8   10,34  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  11,33  SAY  "  select 

8  11,42  GET  selectnum  PICTURE  "9"  RANGE  0,0 

READ 

DO  CASE 

CASE  selectnum  ■  0 
CLEAP  ALL 
RETURN 

CASE  SELECTNUM  -  1 

•JOIN  CMEREQ  WITH  PERSON  TO  JOINFILE  FOR  IDCODE 

•USE  CMEALLOC  AND  GET  ALLOCATION  FOR  SELECTED  FY 

•STORE  ALLOCATION  TO  FY_ALLOCATION 

•USE  JOINFILE  INDEXED  ON  START  DATE 

•SET  FILTER  TO  FY-M_FY 

•SUM  TOTAL  FOR  C_CODE-"A"  TO  AJTOTAL 

•SUM  TOTAL  TOR  C_CODE="E"  TO  E_TOTAL 

•REPORT  WILL  DISPLAY  FY_ALLOCATION  LESS 

•     TOTAL  ESTIMATED  COSTS  REMAINING,  E 


AJTOTAL  AND 
TOTAL 


•ESTIMATED  CME  REPORT  PRINTED  HERE 

CASE  SELECTNUM  -  2 

•JOIN  CMEREQ  WITH  PERSON  TO  JOINFILE  FOR  IDCODE 

•USE  CMEALLOC  AND  GET  ALLOCATION  FOR  SELECTED  FY 

•STORE  ALLOCATION  TO  FY_ALLOCATION 

•USE  JOINFILE  INDEXED  ON  START  DATE 

•SET  FILTER  TO  FY-M_FY 

•SUM  TOTAL  FOR  C_CODE""A" 

•SUM  TOTAL  FOR  C_CODE-"E" 

•SET  FILTER  TO 

•SET  FILTER  TO  C_CODE="A" 

•REPORT  WILL  DISPLAY  FY_ALLOCATION  LESS  AJTOTAL 

•BUT  WILL  NOT  DISPLAY  ESTIMATED  ENTRIES 

•TOTAL  ESTIMATED  COSTS, E  TOTAL,  REMAINING  WILL  BE  A 


TO  AJTOTAL 
TO  E  TOTAL 


.AND.  FY-M  FY 
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COMMENT  AT  BOTTOM 
*     OF  REFOPT 

•ACT"M.  '-MF  PFP^PT  PPTMTFP  HEPE 

ENDCASE 

ENDDO  T 

RETURN 

«  EOF:  PMENU4_4  .  PRG 

~Z 


Program. , 


PMENU5.PRG 


*  Author.  .  . 

*  Date 

*  Notioe. . . 


ELBERT  T.  SHAW  s  JOAN  ZIMMERMAN 
02/02/89 

Copyright  (c)  1989,  ELBERT  T.  SHAW  t  JOAN 
ZIMMERMAN,  All  Rights  Reserved 

*  Notes....:  UPDATE  LEAVE/ABSENSE  REQUESTS 

set  talk  orr 
set  bell  orr 
set  escape  orr 

SET  CONTIRM  ON 
USE  ABSENCE 
M_rY  -  0 

*  Clear  Screen  for  TY  input  an  allow  for  the  user  to  select 
the  Fiscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 
CLEAR 

66,0  to  8,7  9  DOUBLE 

§7,15  SAY  "Enter  the  riscal  Year  for  the  CME  Allocations:"  ; 

GET  M_rY  PICTURE  "99" 
READ 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14,79  DOUBLE 

8  3, 12  SAY  [UPDATE     LEAVE/ABSENCE     LI 
STINGS] 

8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,30  SAY  [1.  ENTER  A  NEW  LEAVE  REQUEST  FOR  TY 
]+STR(M_TY,  2) 

8   8,30  SAY  [2.  CHANGE  CURRENT  LEAVE  INFORMATION  FOP  FY) 
+STR(M_TY,2) 

8   9,30  SAY  [3.  REMOVE  A  LEAVE  REQUEST  FROM  FY 
)+STR(M_FY,  2) 

8  10,30  SAY  [4.  REVIEW  LEAVES  FOR  FY  J +STR (M_FY, 2 ) 

8  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  selectnuro 

8  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  RANGE  0,4 

READ 

DO  CASE 

CASE  selectnum  =  0 
CLEAR  ALL 
RETURN 

CASE  selectnum  <=  1 

*   DO  ADD  INFORMATION 

USE  ABSENCE 

DO  WHILE  .T. 

8  6,0  TO  9, 79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PEPSON  TO  ADD 
THE       LEAVE  REQUEST:  "  GET  M_IDCODE  PICTURE  "!999" 

8  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M_IDCODE«  "" 

EXIT 
ENDIF 

USE  PEPSON 

LOCATE  FOP  IDCODE»M_IDCODE 

IF  FOUND ()  4SPERSON  DOES  EXIST  IN  MASTER  FILE 

ANSWER  ■  "  " 

MZSSAGE=  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/N) 

SET  FORMAT  TO  CONFIRM 

READ 

IF  ANSWER  -  "Y"  *tthe  right  person 

USE  ABSENCE 

SET  TILTER  TO  FY=M_FY 

GO  TOP 

SET  FORMAT  TO  ABSENCE 

APPEND  BLANK 

REPLACE  IDCODE  WITH  M  IDCODE 


REPLACE  FY  WITH  M_rY 

READ 

REPLACE    DURATION   WITH    END-START 

ct.'v-r.  r  rmT 

SEI  FILTER  TO 
LOOP 
ELSE 

LOOP 
ENDIF 
ELSE 

8  6,  0  TO  8,79  DOUBLE 

8  7,15  SAY  "THERE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
LOOP 
ENDIF 
ENDDO 

APPEND 

SET  CONTIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  Key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■»  2 

«   DO  CHANGE  INFORMATION 

DO  WHILE  .T. 
8  6,0  TO  9,79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  YOU 
WANT  TO       CHANGE:  "  GET  M_IDCODE  PICTURE  "!999" 
8  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

IF  M_IDCODE-  "" 

EXIT 
ENDIF 

USE  PERSON 

LOCATE  FOR  IDCODE-M_IDCODE 

IF  rOUNDO  44PERSON  DOES  EXIST  IN  MASTEP  FILE 

ANSWER  -  "  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?   (Y/N) 

SET  FORMAT  TO  CONFIRM 
READ 

IF  ANSWER  -  "Y"  tithe  right  person 
USE  ABSENCE 
CLEAR 
8  6,0 

DISPLAY  FIELDS  IDCODE, TYPE, STAPT, END  WHILE 
IDCODE=M_IDCODE 

8  20,  0  CLEAP 

e    22,0    SAY    "ENTER    THE    RECORD    NUMBER    OF    THE 
LEAVE  REQUEST    YOU   DESIRE    TO    CHANGE.      (1-"       + 

STR(RECCOUNT()  ,*)+")"; 

GET    RECORD    PICTURE    "9999" 
READ 

IF    RECORD    >    0     .AND.     RECORD    <    RECCOUNT ( > 
CLEAR 

GOTO    RECORD 
SET    rORMAT    TO   ABSENCE 
READ 

REPLACE    DURATION   WITH    END-START       HCOMPUTE 
*    or  DAYS 

CLOSE  FORMAT 
EXIT 
ENDDO 
ELSE 

e  20, 0  CLEAR 

8  23,5  SAY  "NO  SUCH  RECORD: 
"  +  STR (RECORD,  4) 

?  CHRP) 
WAIT 
ENDIF 

SET  FILTER  TO 
LOOP 
ELSE 

SET  FILTER  TO 
LOOP 
ENDIF 
ELSE 

8  6,0  TO  8,7  9  DOUBLE 

8  7,15  SAY  "THEFE  IS  NOT  A  PEPSON  WITH  THAT 
IDCODE,  FRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
LOOP 
ENDIF 
ENDDO 
SET  riLTEP  TO 

SET  CONFIRM  OFF 
STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait  subst 
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DELETE 
"1 999" 


FEAD 

SET  CONFIRM  ON 

CASE  selectnum  «  3 

*   DO  REMOVE  INFORMATION 

DO  WHILE  .T. 
6  6,0  TO  9,79  DOUBLE 

8  7,15  SAY  "ENTER  THE  ID  CODE  OF  THE  PERSON  TO 
THEIR  LEAVE  REQUEST:  "  GET  M_IDCODE  PICTURE 

8  8,15  SAY  "OR  PRESS  RETURN  TO  QUIT" 

ir  M_IDCODE-  "" 

EXIT 
ENDir 

USE  PERSON 

LOCATE  FOR  IDCODE-M_IDCODE 

IF  TOUND  O  "PERSON  DOES  EXIST  IN  MASTER  FILE 

ANSWER  -  "  " 

MESSAGE-  "IS  THIS  THE  PERSON  YOU  EXPECTED?  (Y/NI 


SET  FORMAT  TO  CONFIRM 
READ 

IF  ANSWER  ■=  "Y"  lithe  right  person 
USE  ABSENCE 

SET  FILTER  TO  IDCODE»M_IDCODE  .AND.  FY=M_FY 
CLEAR 
6  6,  0 

DISPLAY  FIELDS  IDCODE, TYPE, START,  END  WHILE 
IDCODE=M_IDCODE 
8  20,  0  CLEAR 

8  22,0  SAY  "ENTER  THE  RECORD  NUMBER  OF  THE 
LEAVE  REQUEST  YOU  DESIRE  TO  DELETE.   <l-"+ 

STR(RECCOUNT  () , 4) +") "; 

GET  RECORD  PICTURE  "9999" 
READ 

IT  RECORD  >  0  .AND.  RECORD  <  RECCOUNT() 
GOTO  RECORD 
SET  FORMAT  TO  DELLEAVE 
READ 
IF  UPPER (MAYBE) =  "Y" 

DELETE 
ENDIF 

CLOSE  FORMAT 
ELSE 

8  20, 0  CLEAR 

8  2  3,5  SAY  "NO  SUCH  RECORD: 
"+STR (RECORD, 4) 

?  CHR(7) 
WAIT 
ENDIF 
LOOP 
ELSE 

8  6,0  TO  8,79  DOUBLE 

8  7,15  SAY  "THERE  IS  NOT  A  PERSON  WITH  THAT 
IDCODE,  PRESS  RETURN  TO  TRY  AGAIN..." 

WAIT  "  " 
LOOP 
ENDIT 
ENDDO 

SET  FILTER  TO 
SET  TALK  ON 
CLEAR 

8  2,0  SAY  '  ' 

?  'PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 
DELETION' 
PACK 

SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  *  4 

*   DO  REVIEW  INFORMATION 

SELECT  A 

USE  ABSENCE 

INDEX  ON  IDCODE  TO  TEMP 

SELECT  B 

USE  PERSON 

INDEX  ON  IDCODE  TO  TEMPI 

JOIN  WITH  A  TO  TEMPJOIN  FOR  IDCODE»A->IDCODE  FIELDS 

A->IDCODE,B->RANK,B->FNAME, ; 

B->LNAME, A->TYPE, A->START, A->END, A->DURATION, ; 
A->COMMENT,  A->FY 
USE    TEMPJOIN 
SET    TILTER   TO    TY=M_FY 
BROWSE    NOAPPEND    NOMENU 
ERASE    TEMP.NDX 
ERASE    TEMPI. NDX 


EPASE    TEMP JOIN. DBF 

SET    CONFIRM  OFF 

STORE    '     '     TO    naitsubJt 

8    Ti.!*    SAY    'Pt»i'    any    koy    to    continue 
wait_subst 

READ 

SET    CONFIRM   ON 
ENDCASE 

ENDDO    T 

RETURN 

«    EOF:     PMENU5.PRG 

•■I 


Program.  . 


PHXNT16.PRC 


*  Author...:     ELBERT   T.     SHAW    t    JOAN    ZIMMERMAN 

*  Date :    02/02/89 

*  Notice...:    Copyright    (c)    1989,    ELBERT  T.    SHAW   t    JOAN 
ZIMMERMAN,    All    Rights    Reserved 

*  Notes....:  PRINT  PERSONNEL  REPORTS 

set  talk  orr 

SET  BELL  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
DO  WHILE  .T. 
M_FY  =  0 

*  Clear  Screen  for  FY  input  an  allow  for  the  user  to  select 
the  Fiscal  Year 

*  Typically,  the  user  will  only  be  operating  in  one  FY 
CLEAR 

86,0  to  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Fiscal  Year  for  the  CME  Allocations:"  ; 


GET  M  FY  PICTURE 


"99" 


READ 


* Display 

*     draw  roe 
CLEAR 

e  2,  0  TO  17 
8  3,21  SAY  ( 
]+STR(M_FY,  2) 
8  4,1  TO  4,7 

* display 

7,24  SAY 
8,24  SAY 
9,24  SAY 
10,24  SAY 
11,24  SAY 
12,24  SAY 
13,24  SAY 
15,  24  SAY 
STORE  0  TO 
8  17,33  SAY 
8  17, 42  GET 
READ 


menu  options,  centered  on  the  screen, 
nu  border  and  print  heading 

, 7  9  DOUBLE 

PRINT         REPORTS         TOR 

8    DOUBLE 

detail  lines 
[1.  Position  Listing] 
[2.  Section  Update  Worksheet] 
[3.  Loss  Report] 
[4.  Vacancy  Listing] 
[5.  Social  Roster] 
[7.  Monthly  Absence  Report] 
[8.  Doctor  riscal  Year  Absence  Summary] 

'0.  EXIT' 
electnum 
"select      " 
selectnum  PICTURE  "9"  RANGE  0,8 


DO    CASE 

CASE    selectnum    =    0 
CLEAR   ALL 
RETURN 

CASE    selectnum   a    1 

*      DO    Position    Listing 


•JOIN   APC    WITH    TDA    TO    TEMPJOIN 

•JOIN    TEMPJOIN   WITH    PERSON    FOR    LIKE    TDA    INFORMATION 

•SORT    BY    TDA   POSITION    INFORMATION 

•SUBTOTAL   AUTB    ON    CHANGE    OF    TDA_PARA 

•COUNT    NUMBER   Or    RECORDS    IN   EACH    PARAGRAPH    TO   GET 

ASSIGNED 
•POSITION    LISTING    REPORT    PRINTED    HERE 
•ERASE    ALL   TEMP    FILES 

SET    CONTIPM   OFF 
ST^FE     '      '     10    wait_silbst 

8    23,0    SAY    'Press    any    key    to    continue...'    GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  »  2 

*   DO  Section  Update  Listings 


•JOIN  APC  WITH  TDA  TO  TEMPJOIN 

•JOIN  TEMFJOIN  WITH  FEFSON  FOF  LIKE  TDA  INFORMATION 

•SOFT  BY  TDA  POSITION  INFORMATION 

•SUBTOTAL  AUTH  ON  CHANGE  OF  TDA_PARA 

•COUNT  NUMBER  OF  RECORDS  IN  EACH  PARAGRAPH  TO  GET 
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ASSIGNED 

*SORT  BY  SECTION  CODE  TO  GET  SECTION  BREAKOUTS, 
SECONDARY  SORT  BY  TDA  INFORMATION 

•INCLUDE  BLANK  CHANGE  FIELDS,  TF.F  rXAMPLE  REPORT 

•SECTION  UPDATE  WORKSHEET  REtOFT  FRUITED  HERE 

'ERASE  ALL  TEMF  FILES 

SET  CONTIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnuin  -  3 

*  DO  Loss  Report 

StartDate 

STORE  SPACE (8)  TO  StartDate, EndDato 

CLEAR 

86,  0  to  9,79  DOUBLE 

87,15  SAY  "Enter  the  start  date:"  ; 

GET  StartDate  PICTURE  "99/99/99" 

e  8,15  SAY  "Enter  the  ending  date:"; 
GET  EndDate  PICTURE  "99/99/99" 

READ 

STORE  CTOD (Startdate)  TO  StartDate 

STORE  CTOD  (EndDate)  TO  EndDate 

•JOIN  TDA  KITH  PERSON  TO  TEMPJOIN  FOR  SAME  TDA 
POSITION 

•FIELDS 
RANK.LNAME,  FNAME, JOBTITLE, ALOSS, TDA_PARA, LINE, AND  FOSN 

•  USE  TEMPJOIN  StLIST  OF  ALL  PERSONS  WITH  THEIR 
JOBTITLE 

•INDEX  ON  ALOSS 
•SEEK  STARTDATE 

* DECIDE  WHETHER  TO  PROCEED  WITH  SEEK  APPROACH 

• OR  REVERT  TO  SLOWER,  SAFER  FOP  APPROACH 

•IF  FOUND  0 

•  LIST  WHILE  ALOSS  <=  STARTDATE 

•  IF  POSN=99 

•  USE  TDA 

•  LOCATE  TDAPARA  .AND.  TDA_LINE 

•  PRINT  JOBTITLE 

•  ENDIF 
•ELSE 

•  LIST  FOR  ALOSS  >=  STARTDATE  .AND.  ALOSS  <= 
ENDDATE 

•  IF  POSN=99 

•  USE  TDA 

•  LOCATE    TDA_PARA    .AND.    TDA_LINE 

•  PRINT    JOBTITLE 

•  ENDIF 
•ENDIF 

•LOSS  REPORT  PRINTED  HEFE 
•ERASE  ALL  TEMP  TILES 
SET  CONFIRM  OFF 
STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  Key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnuin  =  4 

*  DO  Vacancy  Listing 

•BLANK  -  "  " 

•JOIN  APC  WITH  TDA  TO  TEMPJOIN 
•JOIN  PERSON  WITH  TEMPJOIN  FOP.  LIKE  TDA 
INFORMATION,  IF  NO         PERSON 

•  MATCHES  A  TDAPOSITION,  LEAVE  IDCODE  AND  LNAME 
BLANK 

•SORT  BY  TDA  POSITION  INFORMATION 

•COUNT  TOR  LNAME  =  BLANK  .AND.  IDCODE  -  BLANK  TO 
TOTAL_VACANT 
•SET  FILTER  TO  IDCODE=BLANK  .AND.  LNAME-BLANK 

•  THIS  SHOULD  ONLY  DISPLAY  THE  VACANT  TDA 
POSITIONS 

•VACANCY  REPORT  PRINTED  HERE 
•ERASE  ALL  TEMP  TILES 
SET  CONFIRM  OFF 
STORE  '   '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_aubst 

READ 

SET  CONFIRM  ON 

CASE  selectnuin  =  5 
I   *   DO  Social  Roster 

•JOIN  PRIVATE  WITH  PERSON  TO  SOCIAL  FOR  IDCODE 

•SOCIAL  ROSTER  PRINTED  HERE 

•ERASE  ALL  TEMP  FILES 

SET  CONTIRM  OTT 

STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 


wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnuni  =  6 

*  DO  MONTHLY  ABSENCE  REPORT 

MONTH  -  0 

8  8,15  SAY  "ENTER  MONTH  (i.e.  1-12)  FOR  THE 
REPORT: "; 

GET  MONTB   PICTURE  "99  "  RANGE  1,12 

READ 

•USE  ABSENCE 

•COPY  TO  TEMPTILE  TIELDS 
IDCODE, START,  END, DURATION, TY, TYPE 

•USE  CMEREQ 

•COPY  TO  ARPENDTILE  TIELDS 

IDCODE, START, END, DURATION, TY.TYPE 

•USE  TEMPTILE 

•APPEND  FROM  APPENDTILE   tt  JOIN  CME  AND  LEAVE 
TILES 

•SORT  BY  "STAFT"  DATE,  "END"  DATE 

•JOIN  PERSON  WITH  TEMPFILE  TO  WHOFILE  is  JOINS 
NAMES         WITH  IDCODE 

•USE  WHOFILE 

•SET  FILTER  TO  FY«M_FY 

•DISPLAY  WHILE  [MONTH  OF  END  DATE)  '   MONTH  .OP. 
[MONTB        OF  STAFT  DATE]  -  MONTH 

•MONTHLY  ABSENCE  REPORT  PRINTED  HERE 

•ERASE  ALL  TEMF  FILES 

SET  CONTIRM  OTT 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnujrt  ■  7 

•  DO  DOCTOR  ABSENCE  REPORT 
M_TY  -  0 

CLEAR, 

86,0  to  8, 79  DOUBLE 

87,15  SAY  "Enter  the  Tiscal  Year  for  the  ABSENCE 
REPORT:"  ; 

GET  MTY  PICTURE  "99" 

READ 

•USE  ABSENCE 

•COPY  TO  TEMPTILE  TIELDS 
IDCODE, START,  END,  DURATION, TY, TYPE  *USE  CMEREQ 

•COPY  TO  APPENDTILE  TIELDS 

IDCODE, START, END, DURATION, FY, TYPE 

•USE  TEMPFILE 

•APPEND  FROM  APPENDFILE   ss  JOIN  CME  AND  LEAVE 
FILES 

•SORT  BY  "START"  DATE,  "END"  DATE 

•JOIN  PERSON  WITH  TEMPFILE  TO  WHOFILE  it  JOINS 
NAMES         WITH  IDCODE 

•USE  WHOFILE 

•SET  FILTER  TO  FY»M_FY 

•INDEX  ON  IDCODE 

•AVERAGE  DURATION  TO  AVGDURATION 

•TOTAL  ON  IDCODE  TO  TOTALSUM  FIELDS  DURATION   HGET 
TOTAL  OF  ALL  ABSENCES 

•ABSENCE  SUMMABY  REPORT  PRINTED  HERE,  PROCEDURE 
LISTED        BELOW 

•DO  WHILE  .NOT.  EOF ( )  tk    SEE  ABSENCE  SUMMARY  REPOPT 

*  IF  IDCODE  HAS  CHANGED  FROM  PREVIOUS  IDCODE 

*  USE  TOTALSUM 

*  LOCATE  CURRENTIDCODE 

*  PRINT  "TOTAL  DAYS  ABSENT"  +  STR  (DURATION,  3) 

*  ENDIF 

*  DISPLAY    CURRENT    RECORD 

*  SKIP    TO   NEXT    RECORD 
•ENDDO 

•ERASE    ALL    TEMP    FILES 
SET    CONFIRM   OFF 
STORE    '     '     TO   wait_subst 

8    23,0   SAY    'Press   any   key   to  continue...'    GET 
wait_subst 

READ 

SET  CONFIRM  ON 

ENDCASE 

ENDDO  T 

RETURN 

•  EOT:  PMENU6.PRG 

"Z 
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APPENDIX  F 


SATISFACTION  PROGRAMS 


TABLE  Or  PROGRAMS 


SMENU.PRG 
SMENU2  .  PRO 
SMENU2_1  .  PPG 
SMENU2_2 . PRG 
SMENU2  3.  PRG 


DISCLAIMER 

The  purpose    of   this  programming   code    is    to 
facilitate   the   understanding   of  the 
requirements  presented  in    Chapter   5   of  this 
thesis.       The  nature   of  this  project   precludes 
it    actual    Implementation   in   DBASE   III+.    To 
fully   implement    the   requirements    the    system 
designer   will    need   a    full    range    of   capabilities 
that    does   not    currently   exist    in   DBASE   III+. 

DBASE   III+   served  as   the  modeling   tool    by 
which   the   screens   were   generated  and   where 
necessary,    specific   code   was    written    to 
illustrate   a  point.    The   actual    working   code 
merely   acts   as   a   shell    in    which    to  run   the 
menus.    A   close   analysis   of  the  program  code   can 
facilitate   implementation   in   a  more   suitable 
language,    i.e.,    PARADOX,    which   can   support    the 
graphics   and  high   level    relationships   involved 
in    the   various   databases .    Where  the  actual 
requirements  process  may   appear   to  be    unclear, 
comments   were   added  within    the   code   to   explain 
these   areas   to   the   designer. 


Program. 


Author .  .  . 

Date 

Notice. .  . 
Notes. . .  . 


■MENU.  PRO 

JOAN  ZIMMERMAN  t    ELBERT  SHAW 

02/19/89 

Copyright  (c)  1989,  All  Rights  Reserved 

Survey  Main  Menu  Program 


SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
DSE  SURVEY 
DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,10  SAY  [DEPARTMENT  OF  FAMILY  PRACTICE  PATIENT  OPINION 

SYSTEM] 
8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,28  SAY  [1.  ENTEP  NEK  SURVEY  DATA] 

8   8,28  SAY  [2.  PRINT  OFINIOll  FES"LTS] 

8  10,  28  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  12, 33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  <=  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  selectnum  =  1 

*   DO  ENTER  NEK  SURVEY  DATA 


SET  FORMAT  TO  SURVEY 

APPEND 

CLOSE  FORMAT 

SET  CONTIRM  OFF 
STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue.., 
wait_subst 

READ 

SET  CONTIRM  ON 

CASE  selectnum  «  2 

*   DO  PRINT  OPINION  RESULTS 

DO  SMENU2 

set  confirm  orr 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'press  any  key  to  continue.., 
wait_subst 

READ 

SET  CONFIRM  ON 
END  CASE 

ENDDO  T 

RETURN 

*  EOF:  SMENU.PRG 


*  Program. . : 

SJOJTO2.PRO 

*  Author...:  JOAN  ZIMMERMAN  t  ELBERT  SHAW 

*  Date :  02/19/89 

*  Notice...:  Copyright  (c)  1989,  All  Rights  Reserved 

*  Notes....:  Print  Opinion  Results 

SET  TALK  OrF 
SET  BELL  OFF 
SET  STATUS  OFF 

set  escape  orr 

SET  CONTIRM  ON 
USE  SURVEY 

DO  HHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  15,79  DOUBLE 

8  3,  21  SAY  [PRINT    OFINION    RESUL 

8  4,1  TO  4,78  DOUBLE 

*  display  detail  lines 

8   7,2  9  SAY  [1.  ACCESS  TO  CARE  REPORTS) 

8   8,29  SAY  [2.  WAITING  TIME  REPORTS] 

8   9,29  SAY  [3.  SATISFACTION  REPORTS) 

8  10,29  SAY  [4.  DOCTOR  REPORTS] 

8  11,29  SAY  [5.  PATIENT  COMMENTS] 

8  13,  29  SAY  '0.  EXIT' 

STORE   0  TO   selectnum 

e    15,33  SAY    "    select 

8    15,42  GET    selectn'ira    PICTURE    "9"    RANGE    0,5 

FEAT 

DO   CASE 

CASE    selectnum    »    0 
RETURN 

CASE    selectnum    *■    1 

*       DO   ACCESS    TO    CARE    REPORTS 

DO    SMENU2_1 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GE 
wait_subst 

READ 
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SET    CONFIRM   ON 

CASE    selectnum    ■    2 

•       t>'    (MIllli    TTI1»    REPORTS 

DO    SMENU2_2 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue... 
wait_subat 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 

»   DO  SATISFACTION  REPORTS 

DO  SMENU2_3 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

6  23,0  SAY  'Press  any  key  to  continue... 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  4 
«   DO  DOCTOR  REPORTS 


CLEAR 

M_YR=0 

M_MO=0 

86,0  TO  9,7  9  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  M_YR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 

*****  Print  Doctor  Satisfaction  Indicator  Report 
here  •*««* 

SET  CONFIRM  OFF 
STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  5 
*   DO  PATIENT  COMMENTS 
CLEAR 
M_MO  =  0 
M_YR  -=  0 

86, 0  TO  9, 79  DOUBLE 
87,15  SAY  "Enter  the  Year:"; 
GET  M_YR  PICTURE  "99" 
RZAD 

88,15  SAY  "Enter  the  Month  for  the  desired 
comments : "; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 
CLEAP 

REPORT  TORM  PATCOMM  FOR  YEAR«M_YR  .AND.  MONTH-M_MO 
.AND.  PATCOMMENTS  =  "Y" 
822,0 
MAIT 
ENDCASE 

ENDDO  T 

RETURN 

*  EOF :  SMENU2 . PRG 

AZ 


Program. 


SMBNU2  1  .  PRG 


*  Author...:  JOAN  ZIMMERMAN  t    ELBERT  SHAW 
«  Date :  02/19/89 

*  Notice...:  Copyright  (c)  1989  All  Rights  Reserved 

*  Notes....:  Access  to  Care  Reports 

SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OrF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 


*  Display  menu  options,  centered  on  the  screen. 

*  drew  menu  border  and  print  heading 
CLEAR 

8  2.  0  TO  12, 79  DOUBLE 

8  3,1°  say  [A  r   c  I  a  n   to   cape   p  e  r  <">  p  t  r\ 

8  4, 1  TO  4, 78  DOUBLE 

*  display  detail  lines 

e   7,32  SAY  [1.  DEPARTMENT  REPORT] 

8   8,32  SAY  (2.  CLINIC  REPORT] 

8  10,  32  SAY  '0.  EXIT' 

STORX  0  TO  selectnum 

8  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  -  1 

*   DO  DEPARTMENT  REPORTS 


CLEAP 

M_YR=0 

M_MO»0 

86,0  TO  9,  79  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  M_YR  PICTURE  "99" 
R£AD 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_M0  PICTURE  "99"  RANGE  1,12 
READ 


Print  Dept .  Acceae  to  Care  Report  here 


SET  CONFIRM  OFF 
STORE  '  '  TO  walt_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■=  2 
«   DO  CLINIC  REFOPTS 

CLEAR 

M_YR»0 

M_MO-0 

86,0  TO  9,  79  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  M_YR  PICTUF.E  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 
CLEAR 

M_CLINIC  -  " 
86, 0  TO  8, 79  DOUBLE 
e7,15  SAY  "Enter  the  Clinic  section  code  for 


GET  M  CLINIC  PICTURE  "8IAAA" 


report : " ; 

READ 
*****  Print  Clinic  Acceaa  to  care  report  here  ***** 


SET  CONFIRM  OFF 

STORE  '  '  TO  weit_subst 

8  2?,0  SAY  'Press  any  key  to  continue.., 
wait_subst 

RIAD 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

«  EOF :  SMENU2  1 . PRG 


*  Program. . 


SMCNU2  2. PP.0 


«  Author...:  JOAN  ZIMMERMAN  6  ELBERT  SHAM 

*  Date :  02/19/89 

*  Notice...:  Copyright  (c)  1989,  All  Rights  Reserved 

*  Notes . . . . :  Waiting  Time  Reports 

SET  TALK  OFF 
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SET  BELL  orr 
SET  STATUS  Off 
SET  ESCAPE  OFF 
SET  CONFIRM  "M 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  beading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,21  SAY  [WAITING    TIME    REPORT  S] 

8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,32  SAY  [1.  DEPARTMENT  REPORT) 

8   8,32  SAY  [2.  CLINIC  REPORT) 

8  10,  32  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  =  0 
RETURN 

CASE  selectnum  -  1 

*   DO  DEPARTMENT  REPORTS 


CLEAR 

MJYR-0 

M_MO-0 

86,0  TO  9,7  9  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  M_YR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 


Print  Dept .  Waiting  Tine  Report  here 


SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  2 
*   DO  CLINIC  REPORTS 

CLEAR 

M_YR-0 

M_MO=0 

86, 0  TO  9,79  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  M_YR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 

CLEAR 

M_CLINIC  -  " 

86,0  TO  8,7  9  DOUBLE 

87,15  SAY  "Enter  the  Clinic  section  code  for 


report :  ' 


GET  M_CLINIC  PICTURE  "8! AAA" 
READ 

*****  Print  Clinic  Waiting  Time  Report  here 


SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue., 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

*     EOF:     SMZNU2_2.PRG 


Program. . 


8MENU2    3.PRG 


Author.  , 
Date.  .  .  . 

Not  i  ce .  . 
Notes . . . 


JOAN    ZIMMERMAN    s    ELBERT    SHAH 

02.  19/?? 

Copyright-     (cl     1»8°,    All    Piohts    Reserved 

Satitffartion    Repf-ifta 


SET    TALK   OFF 
SET    BELL   OFF 
SET    STATUS    Off 
SET    ESCAPE    OFF 
SET    CONFIRM   ON 

DO    WHILE    .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,21  SAY  [SATISFACTION    REPORTS) 

8  4, 1  TO  4, 78  DOUBLE 

*  display  detail  lines 

8   7,32  SAY  [1.  DEPARTMENT  REPORT) 

8   8,32  SAY  [2.  CLINIC  REPORT) 

e  10,  32  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  12,33  SAY  "  select 

8  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  =  1 

*   DO  DEPARTMENT  REPORTS 

CLEAR 

M_YR=0 

M_MO=0 

86,0  TO  9,79  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  MYR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 

*****  Print  Dept .  satisfaction  Report  here  **** 


SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GEI 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  2 
*   DO  CLINIC  REPORTS 

CLEAR 

M_YR-0 

M_MO-0 

86,0  TO  9,79  DOUBLE 

87,15  SAY  "Enter  the  Year  for  report:"; 

GET  MYR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  Month  for  report:"; 

GET  M_MO  PICTURE  "99"  RANGE  1,12 
READ 
CLEAR 

M_CLINIC  -  " 
86,0  TO  8, 79  DOUBLE 
87,15  SAY  "Enter  the  Clinic  section  code  for 


report : 


GET  M_CLINIC  PICTURE  "8! AAA" 
READ 


Print  Clinic  natiafaction  report  here 


SET  CONFIRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO    T 

RETURN 

*    EOF:     SMENU2    3.PRG 
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APPENDIX  G.   PRODUCTIVITY  PROGRAMS 


TABLE  or  PROGRAMS 


VMENU.PRG 
VMENU1 .PRG 
VMINU1_1  .  PRO 
VMENU2.PRG 
VMENU3.PRG 


DISCLAIMER 

The  purpose   of  this  programming   code   is   to 
facilitate   the    understanding   of  the 
requirements  presented  in    Chapter   5  of  this 
thesis.       The  nature   of  this  project   precludes 
it    actual    implementation    in    DBASE   III+.     To 
fully   implement    the   requirements   the   system 
designer  will    need  a    full    range   of  capabilities 
that    does    not    currently   exist    in    DBASE   III+. 

DBASE   III*   served  as    the  modeling   tool    by 
which    the   screens   were   generated   and   where 
necessary,    specific   code   was   written    to 
illustrate  a  point.    The   actual    working   code 
merely   acts   as    a    shell    in    which    to    run    the 
menus.    A   close   analysis   of  the  program  code   can 
facilitate  implementation   in   a  more   suitable 
language,    i.e.,    PARADOX,    which   can   support    the 
graphics   and  high   level    relationships   involved 
in    the   various    databases .    Where   the   actual 
requirements  process  may   appear   to  be    unclear, 
comments   were   added   within    the    code   to   explain 
these   areas   to   the    designer. 


Program. 


VMENU.PRG 


»  Author...:  JOAN  ZIMMERMAN/ELBERT  SHAM 

*  Date :  02/23/89 

•  Notice...:  Copyright  (c)  1989,  All  Rights  Reserved 
SET  TALK  OFF 

SET  BELL  OFT 
SET  STATUS  OFF 
SET  ESCAPE  OrF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  13,79  DOUBLE 

8  3,13  SAY  [DEPARTMENT  OF  FAMILY  PRACTICE  PRODUCTIVITY 

SYSTEM] 
8  4,1  TO  4,7  8  DOUBLE 

*  display  detail  lines 

8   7,25  SAY  [1.  UPDATE  VISIT  FILE] 
8   8,25  SAY  (2.  DEPT  t  CLINIC  PRODUCTIVITY) 
8   9,25  SAY  (3.  EXPENDITURE  'VISIT  COMPARISON] 
8  11,  25  SAY  '0.  EXIT- 
STORE  0  TO  selectnum 
8  13,33  SAY  "  select 

8  13,42  GET  selectnum  PICTURE  "9"  RANGE  0,3 
READ 

DO  CASE 

CASE  selectnum  =  0 
SET  BELL  ON 
SET  TALK  ON 
CLEAR  ALL 
RETURN 

CASE  selectnum  ■  1 

«   DO  UPDATE  VISIT  FILE 


DO  VMENU1 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

e  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  2 

*  DO  DEPT  t    CLINIC  PRODUCTIVITY 

DO  VMENU2 

SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 
8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 

*  DO  EXPENDITURE/VISIT  COMPARISON 

DO  VMENU3 

SET  CONFIRM  OFF 

STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  Key  to  continue. 
wait_subst 

READ 

SET  CONFIRM  ON 
END  CASE 

ENDDO  T 

RETURN 

*  EOF:  VMENU.PRG 


Program. . 


VMENU1.PRG 


JOAN  ZIMMERMAN/ELBERT  SHAH 

02/23/89 

Copyright     (c)     1989,    All    Rights    Reserved 


*  Author 

*  Date. . 

*  Notice 

*  Notes. 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 


*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

e  2,  0  TO  12, 79  DOUBLE 

8    3,24    SAY     [UPDATE         VISIT         FILE] 

8    4,1    TO    4, 78   DOUBLE 

*  display  detail  lines 

8   7,21  SAY  [1.  UPDATE  VISIT  DATA*] 

8   8,21  SAY  [2.  EXTRACT  VISIT  DATA  FROM  MED302  FILE] 

8  10,  21  SAY  '0.  EXIT' 

STORE    0   TO   selectnum 

8    12,33    SAY    "    relect 

8    12,42    CET    selectnum    FT-TTE    "9"    PANCE    0,2 

8    16,15    SAY    "*    T1.1;     -..ption    allows    you    to   enter   visit" 

8    17,15    SAY    "      data    from   the    keyboard." 

READ 

DO   CASE 

CASE  selectnum  »  0 
RETURN 

CASE  selectnum  »  1 

*   DO  ENTEP  VISIT  DATA 

DO  VMENU1_1 

SET  CONFIRM  OFF 

STOPE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
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wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  *=  2 

*   DO  EXTRACT  VISIT  DATA  FROM  MED302  TILE 


*****   Program  to  extract  visit  data  from  roed.302  to 
file  »**•« 

SET  CONriRM  OFF 

STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
walt_aubst 

READ 

SET   CONFIRM  ON 
ENDCASE 

ENDDO   T 

RETURN 

*    EOF:    VMENU1.PRG 


Program. 


WHMTO1    l.PRG 


JOAN    ZIMMERMAN/ELBERT    SHAW 

02/23/89 

Copyright  (c)  1989  All  Rights  Reserved 


*  Author . . 
»  Date. . . . 

*  Notice. . 
SET  TALK  OFF 
SET  BELL  OrF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 
USE  VISIT 

DO  WHILE  .T. 


*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  14, 79  DOUBLE 

8    3,  24    SAY     [UPDATE         VISIT         DATA] 

8    4,1    TO    4,78    DOUBLE 

*  display  detail  lines 

8   7,30  SAY  [1.  ADD  VISIT  DATA) 

8   8,30  SAY  [2.  CHANGE  VISIT  DATA] 

8   9,30  SAY  [3.  REMOVE  VISIT  DATA] 

8  10,30  SAY  [4.  REVIEW  VISIT  DATA] 

e  12,  30  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

6  14,33  SAY  "  select 

8  14,42  GET  selectnum  PICTURE  "9"  PANGE  0,4 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  =  1 

*  DO  ADD  INFORMATION 

SET  FORMAT  TO  VISIT 
APPEND 

SET  FORMAT  TO 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GE 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  ■  2 

*  DO  CHANGE  INFORMATION 

SET  FORMAT  TO  VISIT 
EDIT 

SET  FORMAT  TO 
SET  CONFIRM  OFF 
STORE  '  '  TO  walt_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GE 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  3 

*  DO  REMOVE  INFORMATION 

SET  TALK  ON 


CLEAR 

8  2,0  SAY  '  ' 

?  ' PACKING  DATABASE  TO  REMOVE  RECORDS  MARKED  FOR 
DELETION' 
PACK 

SET  TALK  OFF 
SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  4 

•   DO  REVIEW  INFORMATION 

BROWSE  NOMENU  NOAPPEND 

SET  CONFIRM  OrF 

STORE  '  '  TO  wait_8Ubst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET  CONFIRM  ON 
ENDCASE 

ENDDO  T 

RETURN 

*  EOF:  VMENU1_1.PRG 

-ZAZ 


Program. 


VMKKU2.PRG 


JOAN  ZIMMERMAN/ELBERT  SHAW 

02/23/89 

Copyright  (c)  1989  All  Rights  Reserved 


*  Author . . 

*  Date .... 

*  Notice. . 
SET  TALK  OFF 
SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 


*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,15  SAY  [DEPT    4    CLINIC    PRODUCTIV 
I  T  Y] 

8  4,1  TO  4, 78  DOUBLE 

*  display  detail  lines 

8   7,26  SAY  [1.  TOTAL  MONTH  VISITS] 

8   8,26  SAY  [2.  CLINIC  t    DEPT  VISIT  TRENDS) 

8  10,  26  SAY  '0.  EXIT' 

STORE    0    TO    selectnum 

8    12,33    SAY    "    seloct  " 

8    12,42    GET    selectnum   PICTURE    "9"    RANGE    0,2 

READ 

DO    CASE 

CASE    selectnum   ■    0 
RETURN 

CASE    selectnum   =    1 

*       DO    TOTAL   MONTH    VISITS 

CLEAR 

M_MO-0 

M_YR-0 

86,0    TO    9,  79    DOUBLE 

87,15   SAY    "Enter  the  year   for   report"; 

GET   M_YR    PICTURE    "99" 
READ 
88,15   SAY    "Enter   the  month    for    report"; 

GF.T    MJ10    PICTURE    "99" 
PEAT 


TOTAL   MONTH*    VISIT    BAR    GRAPH    HERE    «*«•« 


SET    CONFIRM   OFF 
STORE    '     '     TO   wait_subst 

8    23,0    SAY    'Press    any    key   to    continue...'    GET 
wait_subst 

READ 

SET  CONFIRM  ON 

CASE  selectnum  =  2 

*   DO  CLINIC  4  DEPT  VISIT  TRENDS 
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M_MO«0 

86, 0  TO  8, 79  DOUBLE 

?7,15  SAY  "Enter  the  year  for  report"; 

CRT  M_YT  f  I-T'T  P  ""l" 
READ 

*****   CLIMIC  t    D«PT  VISIT  TREND  GRAPH  HBRI  ***** 

SET  CONFIRM  OrF 

STORE  '  '  TO  waitsubst 

8  23,0  SAY  'Press  any  key  to  continue...'  GET 
wait_subst 

READ 

SET    CONFIRM   ON 
ENDCASE 

ENDDO    T 

RETURN 

•    EOF:    VMENU2.PRG 


wmmmmmtM\.*mMmm\*\mmr 


*  Program.  . : 

vmn.iM 

»  Author...:  JOAN  ZIMMERMAN/ELBERT  SRAM 

*  Date :  02/23/89 

*  Notice...:  Copyright  (c)  1989,  All  Rights  Reserved 
SET  TALK  OFF 

SET  BELL  OFF 
SET  STATUS  OFF 
SET  ESCAPE  OFF 
SET  CONFIRM  ON 

DO  WHILE  .T. 

*  Display  menu  options,  centered  on  the  screen. 

*  draw  menu  border  and  print  heading 
CLEAR 

8  2,  0  TO  12,79  DOUBLE 

8  3,13  SAY  [EXPENDITURE/VISIT    COMPA 
R  I  S  O  N) 

8  4,1  TO  4, 78  DOUBLE 

* display  detail  lines 

e  7,28  SAY  [1.  CLINIC  EXPENDITURE  PER  VISIT  P-EPOPTJ 

8  8,28  SAY  [2.  DEPT.  EXPENDITURE  VS  VISIT  TREND  REPORT) 

8  10,  28  SAY  '0.  EXIT' 

STORE  0  TO  selectnum 

8  12,33  SAY  "  select 

e  12,42  GET  selectnum  PICTURE  "9"  RANGE  0,2 

READ 

DO  CASE 

CASE  selectnum  ■  0 
RETURN 

CASE  selectnum  =  1 

*   DO  CLINIC  EXPEND.  PER  VISIT 

CLEAR 

M_MO<-0 

M_YR«0 

86,0  TO  9,79  DOUBLE 

87,15  SAY  "Enter  the  year  for  report"; 

GET  M_YR  PICTURE  "99" 
READ 
88,15  SAY  "Enter  the  month  for  report"; 

GET  M_MO  PICTURE  "99" 
READ 

*****  print  Clinic  month*  exp/vi*it  report  here 


SET  CONFIRM  OFF 
STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue.. 
walt_subst 

PEAD 

SET  CONFIRM  ON 

CASE  selectnum  ■  2 

«   DO  EXPEND.  VS  VISIT  TREND 

CLEAR 

M_YR=0 

86,0  TO  8,79  DOUBLE 

87,15  SAY  "Enter  the  year  for  report"; 
GET  M_YR  PICTURE  "99" 

READ 


*****  Print  Dept  EXP  VS  VISIT  TREND  REPORT  HERE 
SET  CONFIRM  OFF 


STORE  '  '  TO  wait_subst 

8  23,0  SAY  'Press  any  key  to  continue. 
wait_subst 

PEAD 

SET    COIIFIPII   Oil 
ENDCASE 

ENDDO    T 

RETURN 

«    EOF:    VMENU1.PRG 

~Z 
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